|
OpenMAMA-2.3.3
Gary Molloy <g.molloy@...>
Hi Guys,
We are currently planning the next release of OpenMAMA - OpenMAMA-2.3.3.
Please find below the initial list of issues that are currently scheduled for inclusion in this release:
BZ166 Make wInterlocked_set return the prior value BZ164 MAMAJNI: MamaPublisher: Overload the MamaPublisher Create Method BZ169 Wombat queue has no separate deallocate method BZ176 MAMAC: Missing actions for snapshot subscriptions transition to deactivate state BZ168 MAMA: Complete support for Vector Bool and Vector Char field types BZ156 COMMON: Variable expansion in property value on the last line of properties file fails BZ125 Payload and Middleware Unit-test in Visual Studio BZ-114 MAMA JNI crash in MamaListen.java when using platformInfo.toString() BZ-178 Problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded BZ-179 OpenMAMA mock RPM's fail to build
If there are any issues in particular you would like to see included in the next release, please feel free to reply (with a prioritised list) and we can review them for inclusion.
Thanks, Gary
Gary Molloy – SR Labs Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD
|
|
|
|
Re: OpenMAMA-2.3.2-rc1
Gary Molloy <g.molloy@...>
Hi Guys,
This reply is a bit later than I anticipated, but I did received some positive feedback from the testing of OpenMAMA-2.3.2-rc1 and so we are ready to make this release final.
The issue with the RPM’s is still unresolved, but this will be resolved and included in the next release.
Glenn, do we have your permission for sign-off?
Thanks, Gary
From: Gary Molloy
Sent: 14 January 2015 16:59 To: openmama-dev@... Subject: RE: OpenMAMA-2.3.2-rc1
Hi Guys,
It’s looking like a fix for the RPM stuff might take a little while longer, so in the interim I’d like to get started with testing of the RC. If you’re interested and happy to get testing, either building yourself or with a binary release, can you drop me a email.
Depending on the availability of testers, we’ll look at reviewing the status the week of the 26th, and decide then if we’re going to require a second RC.
Thanks, Gary
From: Gary Molloy
Hi Guys,
I have cut the new OpenMAMA-2.3.2 branch and created the OpenMAMA-2.3.2-rc1 tag, and this is currently available for testing.
The RPM’s will be delayed unfortunately. It seems that the Fedora repository has updated the default version of proton, to 0.8, and this doesn’t contain the “proton/util.h” header file anymore. This is causing the mock RPM’s to fail as we look for this include file in a few places. I don’t believe that we actually use any of the functions that were in the util.h header, but I will investigate this further, correct it and get the RPMs out as soon as possible.
Thanks, Gary
From: Gary Molloy
Hi Guys,
I will be cutting RC1 for the next release, 2.3.2, this afternoon.
This will contain a handful of minor issues, unit tests updates, enterprise issues etc…
If there are any issues in particular you would like to see included in the next release, please feel free to reply and we can review any issue for inclusion.
Thanks, Gary
Gary Molloy – SR Labs Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD
|
|
|
|
Re: Subscription onDestroy Callback
Alpert, Reed <reed.alpert@...>
Hi,
Does the onDestroy() guarantee that no more callbacks will be made for that subscription? Similar to Reuters completion event. To guarantee this it seems it must be posted as an event on the sub queue, and no more sent after that.
For destroy/create use case: sub->destroy(); wait for onDestroy(); sub->create(>..);
What issues did the sample apps have?
Thanks,
Reed.
Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198 | M: 917.414.4613 | reed.alpert@... Alternate Contact: CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...
-----Original Message-----
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Sam Wilson Sent: Wednesday, February 18, 2015 3:05 PM To: openmama-dev@... Subject: [Openmama-dev] Subscription onDestroy Callback
Hey everyone,
I spoke quickly with Damien about this on IRC, but I thought I should raise the question with the community at large.
What thread should the subscription's onDestroy callback be called from? We recently switched from calling it on a thread controlled by the bridge to enqueuing it on the subscription's queue, but that seems to cause a lot of trouble for the sample applications.
Section 9 of the OpenMAMA Developer's Guide for C leaves out the onDestroy callback.
Thanks, Sam _______________________________________________ Openmama-dev mailing list https://lists.openmama.org/mailman/listinfo/openmama-dev This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. |
|
|
|
Re: Notification for new subscriptions
Ian Bell <i.bell@...>
Hi
Can you attach the full patch for a full look? It seems like the DQPublishermanager create callback does not directly return the closure, unlike the normal subscription / basic subscription OnCreate callback. Therefore you should use the getclosure api to obtain it. Similar to what happens in the JNI version.
static void MAMACALLTYPE mamaDQPublisherManagerOnCreateCb (mamaDQPublisherManager manager) { JNIEnv* env = NULL; dqcallbackClosure* closureImpl = (dqcallbackClosure*)mamaDQPublisherManager_getClosure(manager);
There is no specific documentation on creating the wrappers but in general you shold be able to work in a similar way to the existing CPP and JNI wrappers.
Thanks Ian
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Mathias Kim
Sent: 19 February 2015 13:06 To: openmama-dev@... Subject: Re: [Openmama-dev] Notification for new subscriptions
Hi again,
I made a mistake in my previous mail. We tried to implement the dqpublishermanager, not the dqpublisher.
Best regards
Mathias
From:
openmama-dev-bounces@...
[mailto:openmama-dev-bounces@...]
On Behalf Of Mathias Kim
Hi all,
we put some effort into this and came up with an implementation of the dqpublisher, but the code fails when the onCreate callback is called. When we try to convert the closure pointer to an handle we get a FatalExecutionEngineError (error code 0xc0000005). Since we have limited experience with wrapping c code for .net, we just did it in the way you did for the BasicSubscriber. As we get a callback from the c class, we think we’re on the right path. Nonetheless, the values we get back (closure) seems to point to the wrong place in the memory.
private static void onCreate(IntPtr NativeHandle, IntPtr closure) { GCHandle handle = GCHandle.FromIntPtr(closure); //code fails in this line MamaDQPublishManagerImpl impl = (MamaDQPublishManagerImpl)handle.Target; impl.InvokeCreate();
}
Therefore we ask ourselves: - Are we doing it right? - Is there something like a manual on how to wrap c classes for .net - Sometimes a *impl class is used, sometime the MamaCallbackWrapper class. Where is the difference and when do you use which?
If needed, our code can be provided.
Best regards
Mathias
From:
openmama-dev-bounces@...
[mailto:openmama-dev-bounces@...]
On Behalf Of Glenn McClements
Hi Mathias,
As Paul pointed out, what you would really want is DQPublisher for C#, but unfortunately there isn’t one at the moment. The reason for this is that that previously there hasn’t been a real demand as most C# applications have been on the client subscribing side, not the publishing side.
It sounds like there are a least a few people now looking for one so I’d be interested in finding out if there are others out there looking the same and if anyone if willing to contribute code in this are?
Also to clarify: The MamaPublisher “basic" publishing ie. without sequence numbers, initial images/recaps etc or any other market data/data quality type features. The equivalent class on the subscribing side is MamaBasicSubscription.
The MamaDQPublisher and associated classes have sequence number injection, callbacks when a client subscription is made etc. The equivalent class on the subscribing side is MamaSubscription.
Cheers, Glenn
From:
Paul Bradbury <paul.bradbury@...>
From what I recall there, are no .net wrappers for the DQPublisher as yet (although somewhat unfairly there are in the Java codebase!). For me as a greenfield application, it was simpler to write in C++, but I think adding those wrappers wasn’t too big a deal as they were really just wrappers along the lines of the existing code for the normal publisher.
Paul.
From:
openmama-dev-bounces@...
[mailto:openmama-dev-bounces@...]
On Behalf Of Kim Mathias
Hi,
Currently, I am trying to set up a publisher for market data with OpenMAMA in C#. I wonder if there is a way to receive a notifcation every time my publisher accepts a new subscription from a subscriber? Is there an event thrown that I can handle?
Also, I still don't completely understand the difference between a basic publisher and an advanced publisher. In the development guide, the latter is only mentioned but never described in detail (e.g. how to use it).
Best regards
Mathias No virus found in this message. |
|
|
|
Re: Starting a bridge in a new thread
Ian Bell <i.bell@...>
Hi
Either option is fine as Mama.start is a blocking call until Mama.stop is called, which causes it to return. For the second one you should be aware that the call-back is invoked after Mama.start has returned, i.e. after Mama.stop is called. Think of it as onStopComplete rather than start. The reason for this is so that you know when it is safe to destroy transports, queues etc on shutdown. If you use option 1 you need to take care of this interaction yourself.
Thanks Ian
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Hari Shyam
Sent: 19 February 2015 17:07 To: openmama-dev@... Subject: [Openmama-dev] Starting a bridge in a new thread
Hi team,
Is it necessary to start a bridge on a separate thread?
new Thread() { public void run() { try { Mama.start(bridge); } catch (RuntimeException e) { } }.start(); } }
Or should we use this
Mama.startBackground(bridge, new MamaStartBackgroundCallback() {
@Override public void onStartComplete(int paramInt) {
logger.info("mama started");
} });
For the second option, the callback is never called.
Thanks,
|
|
|
|
Starting a bridge in a new thread
Hari Shyam <hari.shyam@...>
Hi team,
Is it necessary to start a bridge on a separate thread?
new Thread() { public void run() { try { Mama.start(bridge); } catch (RuntimeException e) { } }.start(); } }
Or should we use this
Mama.startBackground(bridge, new MamaStartBackgroundCallback() {
@Override public void onStartComplete(int paramInt) {
logger.info("mama started");
} });
For the second option, the callback is never called.
Thanks, --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy. |
|
|
|
Re: Notification for new subscriptions
Mathias Kim
Hi again,
I made a mistake in my previous mail. We tried to implement the dqpublishermanager, not the dqpublisher.
Best regards
Mathias
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Mathias Kim
Sent: Donnerstag, 19. Februar 2015 13:46 To: openmama-dev@... Subject: Re: [Openmama-dev] Notification for new subscriptions
Hi all,
we put some effort into this and came up with an implementation of the dqpublisher, but the code fails when the onCreate callback is called. When we try to convert the closure pointer to an handle we get a FatalExecutionEngineError (error code 0xc0000005). Since we have limited experience with wrapping c code for .net, we just did it in the way you did for the BasicSubscriber. As we get a callback from the c class, we think we’re on the right path. Nonetheless, the values we get back (closure) seems to point to the wrong place in the memory.
private static void onCreate(IntPtr NativeHandle, IntPtr closure) { GCHandle handle = GCHandle.FromIntPtr(closure); //code fails in this line MamaDQPublishManagerImpl impl = (MamaDQPublishManagerImpl)handle.Target; impl.InvokeCreate();
}
Therefore we ask ourselves: - Are we doing it right? - Is there something like a manual on how to wrap c classes for .net - Sometimes a *impl class is used, sometime the MamaCallbackWrapper class. Where is the difference and when do you use which?
If needed, our code can be provided.
Best regards
Mathias
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Glenn McClements
Hi Mathias,
As Paul pointed out, what you would really want is DQPublisher for C#, but unfortunately there isn’t one at the moment. The reason for this is that that previously there hasn’t been a real demand as most C# applications have been on the client subscribing side, not the publishing side.
It sounds like there are a least a few people now looking for one so I’d be interested in finding out if there are others out there looking the same and if anyone if willing to contribute code in this are?
Also to clarify: The MamaPublisher “basic" publishing ie. without sequence numbers, initial images/recaps etc or any other market data/data quality type features. The equivalent class on the subscribing side is MamaBasicSubscription.
The MamaDQPublisher and associated classes have sequence number injection, callbacks when a client subscription is made etc. The equivalent class on the subscribing side is MamaSubscription.
Cheers, Glenn
From:
Paul Bradbury <paul.bradbury@...>
From what I recall there, are no .net wrappers for the DQPublisher as yet (although somewhat unfairly there are in the Java codebase!). For me as a greenfield application, it was simpler to write in C++, but I think adding those wrappers wasn’t too big a deal as they were really just wrappers along the lines of the existing code for the normal publisher.
Paul.
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Kim Mathias
Hi,
Currently, I am trying to set up a publisher for market data with OpenMAMA in C#. I wonder if there is a way to receive a notifcation every time my publisher accepts a new subscription from a subscriber? Is there an event thrown that I can handle?
Also, I still don't completely understand the difference between a basic publisher and an advanced publisher. In the development guide, the latter is only mentioned but never described in detail (e.g. how to use it).
Best regards
Mathias No virus found in this message. |
|
|
|
Re: Notification for new subscriptions
Mathias Kim
Hi all,
we put some effort into this and came up with an implementation of the dqpublisher, but the code fails when the onCreate callback is called. When we try to convert the closure pointer to an handle we get a FatalExecutionEngineError (error code 0xc0000005). Since we have limited experience with wrapping c code for .net, we just did it in the way you did for the BasicSubscriber. As we get a callback from the c class, we think we’re on the right path. Nonetheless, the values we get back (closure) seems to point to the wrong place in the memory.
private static void onCreate(IntPtr NativeHandle, IntPtr closure) { GCHandle handle = GCHandle.FromIntPtr(closure); //code fails in this line MamaDQPublishManagerImpl impl = (MamaDQPublishManagerImpl)handle.Target; impl.InvokeCreate();
}
Therefore we ask ourselves: - Are we doing it right? - Is there something like a manual on how to wrap c classes for .net - Sometimes a *impl class is used, sometime the MamaCallbackWrapper class. Where is the difference and when do you use which?
If needed, our code can be provided.
Best regards
Mathias
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Glenn McClements
Sent: Dienstag, 27. Januar 2015 18:22 To: Paul Bradbury; openmama-dev@... Subject: Re: [Openmama-dev] Notification for new subscriptions Mathias
Hi Mathias,
As Paul pointed out, what you would really want is DQPublisher for C#, but unfortunately there isn’t one at the moment. The reason for this is that that previously there hasn’t been a real demand as most C# applications have been on the client subscribing side, not the publishing side.
It sounds like there are a least a few people now looking for one so I’d be interested in finding out if there are others out there looking the same and if anyone if willing to contribute code in this are?
Also to clarify: The MamaPublisher “basic" publishing ie. without sequence numbers, initial images/recaps etc or any other market data/data quality type features. The equivalent class on the subscribing side is MamaBasicSubscription.
The MamaDQPublisher and associated classes have sequence number injection, callbacks when a client subscription is made etc. The equivalent class on the subscribing side is MamaSubscription.
Cheers, Glenn
From:
Paul Bradbury <paul.bradbury@...>
From what I recall there, are no .net wrappers for the DQPublisher as yet (although somewhat unfairly there are in the Java codebase!). For me as a greenfield application, it was simpler to write in C++, but I think adding those wrappers wasn’t too big a deal as they were really just wrappers along the lines of the existing code for the normal publisher.
Paul.
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Kim Mathias
Hi,
Currently, I am trying to set up a publisher for market data with OpenMAMA in C#. I wonder if there is a way to receive a notifcation every time my publisher accepts a new subscription from a subscriber? Is there an event thrown that I can handle?
Also, I still don't completely understand the difference between a basic publisher and an advanced publisher. In the development guide, the latter is only mentioned but never described in detail (e.g. how to use it).
Best regards
Mathias No virus found in this message. |
|
|
|
Subscription onDestroy Callback
Sam Wilson <Sam.Wilson@...>
Hey everyone,
I spoke quickly with Damien about this on IRC, but I thought I should raise the question with the community at large. What thread should the subscription's onDestroy callback be called from? We recently switched from calling it on a thread controlled by the bridge to enqueuing it on the subscription's queue, but that seems to cause a lot of trouble for the sample applications. Section 9 of the OpenMAMA Developer's Guide for C leaves out the onDestroy callback. Thanks, Sam |
|
|
|
Re: Java missing method and junit tests
Gary Molloy <g.molloy@...>
Hi Reed,
Currently we have no development activity in the Java code base. Please go ahead and submit your patch(s)
Thanks, Gary
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Alpert, Reed
Sent: 29 January 2015 15:58 To: openmama-dev@... Subject: [Openmama-dev] Java missing method and junit tests
Hi,
I am working with the java interface as the Metafluent vendor (market data over JMS) is adding OpenMAMA support for the Tick42/RMDS, Solace, and SRLabs bridges.
I’ve prepared a patch for a missing method (MamaDateTime.getAsFormattedString), and was adding a junit test and noticed: 1. The junit tests require wmw and a transport named sub_wmw_5 to be available. I’d like to make that configurable in the tests via cmd line args to Main. 2. Scons does not build the junit when using with_unittest=true (prepared a patch for that also). 3. The Scons build puts the junit classes in mamajni.jar (same as testtools), which is OK for us since we only build unit tests for dev. 4. The junit classes don’t have a package, so they are in the root of mamajni.jar, which works, but probably should be in a package path.
My question is is there a dev effort for java interface now? I can submit patches for all of this, but want to coordinate with any active dev in the java area.
Thanks,
Reed.
Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198 | M: 917.414.4613 | reed.alpert@...
Alternate Contact: CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...
From: Glenn McClements [mailto:g.mcclements@...]
Any input around this area is very welcome, especially coming from people newish to the project with a fresh pair of eyes.
Questions like the below I flag for addition to the FAQ or wiki, but so if there’s any other gotchas you’ve encountered or areas that you think need to be clarified let me know.
Cheers, Glenn
From: Alireza Assadzadeh
Glenn,
Thanks for your reply and confirmations.
Also it sounds good about updating the wiki in this area. If you need any additional input from my side, please let me know.
Regards
--Alireza
From: Glenn McClements [mailto:g.mcclements@...]
Yep, the SR Labs TCP middleware does exactly as you suggest, in that there is a second disconnect call back when the reconnects have finally failed. We’ll add this note to the bridge wiki as well.
There is the platformInfo parameter in the callback which could be used to pass back extra info but it’s no where near ideal for this as it’s a void* - the use of this is historical where there has been a need to pass back middleware specific items, but this is not usable across middlewares in its current form.
I’m fully supportive of enhancing this area in a future release as long it there is a) a desire for it out there and b) a way we can implement it in a backward compatible manner.
Cheers, Glenn
From: Alireza Assadzadeh <Alireza.Assadzadeh@...>
Hi,
Glen and Reed, thank you for your responses.
Open (2) sounds good. Given the current (2.3.x) functionality of OpenMAMA and the importance of using a consistent/safe approach for current users, I also think option (2) is our best choice.
Option (2): (a) onDisconnect (b) onReconnect
For the Solace OpenMAMA Middleware Bridge, we will use Option (2) then.
I would like to also highlight and reconfirm that for option (2), in scenario we have “(c) if all reconnect attempts fail, at the time of the last reconnect failure, the provides a MAMA_TRANSPORT_DISCONNECT”. Therefore, in the reconnect failure scenario, there are two disconnect notifications provided to the application. Do you see any issues with generating the second onDisconnect back to back (without a matching onReconnect or onConnect)? Does the SR Labs TCP middleware also generate two onDisconnect notifications for the reconnect failure scenario?
I didn’t notice any requirements in the OpenMAMA codebase against generating the second onDisconnect for the reconnect failure scenario. If generating the second onDisconnect is ok, I was thinking we could populate additional information in the ‘cause’ and/or ‘platfromInfo’ for any application that is interested in realizing the difference between the two onDisconnect notifications types (which would be Middleware specific, since ‘cause’ does not have a predefined/standardized set of values).
Regarding future enhancements, if there is sufficient interest in the community about a separate state for Reconnecting, we could consider adding support for it in a future OpenMAMA release (for Middleware bridges that have the capability).
--Alireza
From: Alpert, Reed [mailto:reed.alpert@...]
Hi,
For us consistency between the bridges is the most important item.
Tick42/RMDS also uses the onDisconnect/OnReconnect model (and sends STALE status for each subscription).
Both Tick42 and Solace offer, via config, to re-establish each of the subscriptions, so our apps don’t do anything when we get an onDisconnect (except stop any publishing), and then wait for onReconnect and the following INITIALs.
It would be good to have a notice that a transport could not be reconnected and the bridge has closed the transport (both Solace and Tick42 have configurable limited retries). In that case the app needs to raise a support request to Operations.
It is the case that onQuality(STALE) followed by onQuality(OK) could accomplish the same thing in our case, as the app would simply wait, but keeping the bridge behavior the same makes for less moving parts.
Thanks,
Reed.
Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198 | M: 917.414.4613 | reed.alpert@...
Alternate Contact: CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...
From:openmama-dev-bounces@...
[mailto:openmama-dev-bounces@...]
On Behalf Of Glenn McClements
Hi Alireza,
Currently for the SR Labs TCP middleware, which is the closest in behaviour to Solace we do:
Option (2): (a) onDisconnect (b) onReconnect
So this would be the most consistent/safest options for current users (this will also trigger an onPossiblyStale for the subscriptions on that transport btw).
You’re right though that people may want to distinguish between a temporary disconnect and a permanent disconnect, in order to only perform the more drastic cleanup type behaviour when a permanent disconnect happens, but there currently isn’t a clean way to do this.
Your solution is analogous to PossiblyStale for the subscriptions, which goes to OK or Stale depending on the whether a message has been missed. We could have a Reconnecting state which would then go to Connected or Disconnected depending on outcome of the retry logic. At the moment I’d say this would be a nice to have for future consideration though as I don’t recall this coming up before from a customer request before.
We’ll update the bridge wiki with the above behaviour http://wiki.openmama.org/index.php/OpenMAMA_Bridge_Documentation
Apologies in the delay for getting back btw.
Cheers, Glenn
From: Alireza Assadzadeh <Alireza.Assadzadeh@...>
Hi Folks,
Some middleware bridges may have the capability to automatically reconnect to their messaging infrastructure after a connection failure, for example at the TCP/socket layer. In OpenMAMA C layer, there is the mamaTransportCB and the mamaTransportEvent enum to allow notification about different transport conditions from the middleware bridge to OpenMAMA layer and to the application. In MAMA C++, there is MamaTransportCallback which provides similar notification for a C++ application, for example using onConnect, onDisconnect, onReconnect, and onQuality. There are similar notification mechanisms for the application for other OpenMAMA supported language bindings such as Java and C#.
I was looking at what would be a commonly expected and accepted behaviour when the middleware bridge automatically reconnects the connection and was hoping to get your input.
Consider the case that a middleware bridge notices a connection failure on a previously established connection. The middleware bridge that is capable of automatically reconnecting then automatically starts a retry mechanism for a predefined number of attempts and may eventually either succeed or fail to reestablish the connection. A middleware that is not capable of automatically reconnecting would provide a disconnect event to the application.
For this scenario there are several conceivable options for the middleware bridge and OpenMAMA to provide notifications to the application:
One option is the following: (a) When connection is lost, provide a MAMA_TRANSPORT_QUALITY event. (b) If the connection is successfully reestablished, at the time it is reestablished, provide MAMA_TRANSPORT_RECONNECT event. (c) If all reconnect attempts fail, at the time of the last reconnect failure, provide a MAMA_TRANSPORT_DISCONNECT.
Another option is that for condition (a), provide a MAMA_TRANSPORT_DISCONNECT event (instead of MAMA_TRANSPORT_QUALITY).
Yet another option is that for condition (b), provide a MAMA_TRANSPORT_QUALITY event (instead of MAMA_TRANSPORT_RECONNECT). For this option (a) and (b) are differentiated by the application using different values for ‘cause’ in the callback and transport quality is changed accordingly.
Here are the above three options summarized using the C++ callback names as shorthand. There are other options, but I think these three illustrate the flexibility / interpretation and the need for elaborating in this area.
Option (1): (a) onQuality(cause=1) (b) onReconnect Option (2): (a) onDisconnect (b) onReconnect Option (3): (a) onQuality(cause=1) (b) onQuality(cause=0)
For option (1) there may also be an onQuality(cause=0) after the connection is reestablished if the transport has a marketdata subscription with recover gaps and new messaging arrive do not have gaps.
We had initially been thinking about implementing option (1) in the Solace OpenMAMA Middleware Bridge. One concern we had with using option (2) was that the onDisconnect may result in a typical application itself to clean up the transport and possibly take transport reconnect actions rather than allowing a middleware (that is capable of doing the automatic reconnect) to perform its reconnect attempts.
Another option is enhance the transport callback. For example, to provide a onReconnecting callback when a connection is lost and the middleware is in the state of “reconnecting” the lost connection. However, adding a new callback would require a new OpenMAMA version and may be a longer term possibility to think about.
It is valuable to provide a consistent and clear behaviour to the applications in this area, specially across different middleware bridge types. What is the expected behaviour and design of OpenMAMA for these notifications and what do other bridges do in these cases?
Regards,
--Alireza This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. |
|
|
|
Java missing method and junit tests
Alpert, Reed <reed.alpert@...>
Hi,
I am working with the java interface as the Metafluent vendor (market data over JMS) is adding OpenMAMA support for the Tick42/RMDS, Solace, and SRLabs bridges.
I’ve prepared a patch for a missing method (MamaDateTime.getAsFormattedString), and was adding a junit test and noticed: 1. The junit tests require wmw and a transport named sub_wmw_5 to be available. I’d like to make that configurable in the tests via cmd line args to Main. 2. Scons does not build the junit when using with_unittest=true (prepared a patch for that also). 3. The Scons build puts the junit classes in mamajni.jar (same as testtools), which is OK for us since we only build unit tests for dev. 4. The junit classes don’t have a package, so they are in the root of mamajni.jar, which works, but probably should be in a package path.
My question is is there a dev effort for java interface now? I can submit patches for all of this, but want to coordinate with any active dev in the java area.
Thanks,
Reed.
Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198 | M: 917.414.4613 | reed.alpert@...
Alternate Contact: CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...
From: Glenn McClements [mailto:g.mcclements@...]
Sent: Wednesday, January 28, 2015 9:37 AM To: Alireza Assadzadeh; Alpert, Reed; openmama-dev@... Subject: Re: [Openmama-dev] Transport callbacks when a middleware bridge automatically reconnects a transport
Any input around this area is very welcome, especially coming from people newish to the project with a fresh pair of eyes.
Questions like the below I flag for addition to the FAQ or wiki, but so if there’s any other gotchas you’ve encountered or areas that you think need to be clarified let me know.
Cheers, Glenn
From: Alireza Assadzadeh
Glenn,
Thanks for your reply and confirmations.
Also it sounds good about updating the wiki in this area. If you need any additional input from my side, please let me know.
Regards
--Alireza
From: Glenn McClements [mailto:g.mcclements@...]
Yep, the SR Labs TCP middleware does exactly as you suggest, in that there is a second disconnect call back when the reconnects have finally failed. We’ll add this note to the bridge wiki as well.
There is the platformInfo parameter in the callback which could be used to pass back extra info but it’s no where near ideal for this as it’s a void* - the use of this is historical where there has been a need to pass back middleware specific items, but this is not usable across middlewares in its current form.
I’m fully supportive of enhancing this area in a future release as long it there is a) a desire for it out there and b) a way we can implement it in a backward compatible manner.
Cheers, Glenn
From: Alireza Assadzadeh <Alireza.Assadzadeh@...>
Hi,
Glen and Reed, thank you for your responses.
Open (2) sounds good. Given the current (2.3.x) functionality of OpenMAMA and the importance of using a consistent/safe approach for current users, I also think option (2) is our best choice.
Option (2): (a) onDisconnect (b) onReconnect
For the Solace OpenMAMA Middleware Bridge, we will use Option (2) then.
I would like to also highlight and reconfirm that for option (2), in scenario we have “(c) if all reconnect attempts fail, at the time of the last reconnect failure, the provides a MAMA_TRANSPORT_DISCONNECT”. Therefore, in the reconnect failure scenario, there are two disconnect notifications provided to the application. Do you see any issues with generating the second onDisconnect back to back (without a matching onReconnect or onConnect)? Does the SR Labs TCP middleware also generate two onDisconnect notifications for the reconnect failure scenario?
I didn’t notice any requirements in the OpenMAMA codebase against generating the second onDisconnect for the reconnect failure scenario. If generating the second onDisconnect is ok, I was thinking we could populate additional information in the ‘cause’ and/or ‘platfromInfo’ for any application that is interested in realizing the difference between the two onDisconnect notifications types (which would be Middleware specific, since ‘cause’ does not have a predefined/standardized set of values).
Regarding future enhancements, if there is sufficient interest in the community about a separate state for Reconnecting, we could consider adding support for it in a future OpenMAMA release (for Middleware bridges that have the capability).
--Alireza
From: Alpert, Reed [mailto:reed.alpert@...]
Hi,
For us consistency between the bridges is the most important item.
Tick42/RMDS also uses the onDisconnect/OnReconnect model (and sends STALE status for each subscription).
Both Tick42 and Solace offer, via config, to re-establish each of the subscriptions, so our apps don’t do anything when we get an onDisconnect (except stop any publishing), and then wait for onReconnect and the following INITIALs.
It would be good to have a notice that a transport could not be reconnected and the bridge has closed the transport (both Solace and Tick42 have configurable limited retries). In that case the app needs to raise a support request to Operations.
It is the case that onQuality(STALE) followed by onQuality(OK) could accomplish the same thing in our case, as the app would simply wait, but keeping the bridge behavior the same makes for less moving parts.
Thanks,
Reed.
Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198 | M: 917.414.4613 | reed.alpert@...
Alternate Contact: CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...
From:openmama-dev-bounces@...
[mailto:openmama-dev-bounces@...]
On Behalf Of Glenn McClements
Hi Alireza,
Currently for the SR Labs TCP middleware, which is the closest in behaviour to Solace we do:
Option (2): (a) onDisconnect (b) onReconnect
So this would be the most consistent/safest options for current users (this will also trigger an onPossiblyStale for the subscriptions on that transport btw).
You’re right though that people may want to distinguish between a temporary disconnect and a permanent disconnect, in order to only perform the more drastic cleanup type behaviour when a permanent disconnect happens, but there currently isn’t a clean way to do this.
Your solution is analogous to PossiblyStale for the subscriptions, which goes to OK or Stale depending on the whether a message has been missed. We could have a Reconnecting state which would then go to Connected or Disconnected depending on outcome of the retry logic. At the moment I’d say this would be a nice to have for future consideration though as I don’t recall this coming up before from a customer request before.
We’ll update the bridge wiki with the above behaviour http://wiki.openmama.org/index.php/OpenMAMA_Bridge_Documentation
Apologies in the delay for getting back btw.
Cheers, Glenn
From: Alireza Assadzadeh <Alireza.Assadzadeh@...>
Hi Folks,
Some middleware bridges may have the capability to automatically reconnect to their messaging infrastructure after a connection failure, for example at the TCP/socket layer. In OpenMAMA C layer, there is the mamaTransportCB and the mamaTransportEvent enum to allow notification about different transport conditions from the middleware bridge to OpenMAMA layer and to the application. In MAMA C++, there is MamaTransportCallback which provides similar notification for a C++ application, for example using onConnect, onDisconnect, onReconnect, and onQuality. There are similar notification mechanisms for the application for other OpenMAMA supported language bindings such as Java and C#.
I was looking at what would be a commonly expected and accepted behaviour when the middleware bridge automatically reconnects the connection and was hoping to get your input.
Consider the case that a middleware bridge notices a connection failure on a previously established connection. The middleware bridge that is capable of automatically reconnecting then automatically starts a retry mechanism for a predefined number of attempts and may eventually either succeed or fail to reestablish the connection. A middleware that is not capable of automatically reconnecting would provide a disconnect event to the application.
For this scenario there are several conceivable options for the middleware bridge and OpenMAMA to provide notifications to the application:
One option is the following: (a) When connection is lost, provide a MAMA_TRANSPORT_QUALITY event. (b) If the connection is successfully reestablished, at the time it is reestablished, provide MAMA_TRANSPORT_RECONNECT event. (c) If all reconnect attempts fail, at the time of the last reconnect failure, provide a MAMA_TRANSPORT_DISCONNECT.
Another option is that for condition (a), provide a MAMA_TRANSPORT_DISCONNECT event (instead of MAMA_TRANSPORT_QUALITY).
Yet another option is that for condition (b), provide a MAMA_TRANSPORT_QUALITY event (instead of MAMA_TRANSPORT_RECONNECT). For this option (a) and (b) are differentiated by the application using different values for ‘cause’ in the callback and transport quality is changed accordingly.
Here are the above three options summarized using the C++ callback names as shorthand. There are other options, but I think these three illustrate the flexibility / interpretation and the need for elaborating in this area.
Option (1): (a) onQuality(cause=1) (b) onReconnect Option (2): (a) onDisconnect (b) onReconnect Option (3): (a) onQuality(cause=1) (b) onQuality(cause=0)
For option (1) there may also be an onQuality(cause=0) after the connection is reestablished if the transport has a marketdata subscription with recover gaps and new messaging arrive do not have gaps.
We had initially been thinking about implementing option (1) in the Solace OpenMAMA Middleware Bridge. One concern we had with using option (2) was that the onDisconnect may result in a typical application itself to clean up the transport and possibly take transport reconnect actions rather than allowing a middleware (that is capable of doing the automatic reconnect) to perform its reconnect attempts.
Another option is enhance the transport callback. For example, to provide a onReconnecting callback when a connection is lost and the middleware is in the state of “reconnecting” the lost connection. However, adding a new callback would require a new OpenMAMA version and may be a longer term possibility to think about.
It is valuable to provide a consistent and clear behaviour to the applications in this area, specially across different middleware bridge types. What is the expected behaviour and design of OpenMAMA for these notifications and what do other bridges do in these cases?
Regards,
--Alireza This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. |
|
|
|
Re: Transport callbacks when a middleware bridge automatically reconnects a transport
Glenn McClements <g.mcclements@...>
Any input around this area is very welcome, especially coming from people newish to the project with a fresh pair of eyes.
Questions like the below I flag for addition to the FAQ or wiki, but so if there’s any other gotchas you’ve encountered or areas that you think need to be clarified let me know.
Cheers,
Glenn
From: Alireza Assadzadeh
Date: Wednesday, 28 January 2015 13:38 To: Glenn McClements, "Alpert, Reed", "openmama-dev@..." Subject: RE: [Openmama-dev] Transport callbacks when a middleware bridge automatically reconnects a transport Glenn,
Thanks for your reply and confirmations.
Also it sounds good about updating the wiki in this area. If you need any additional input from my side, please let me know.
Regards
--Alireza
From: Glenn McClements [mailto:g.mcclements@...]
Sent: Tuesday, January 27, 2015 12:08 PM To: Alireza Assadzadeh; Alpert, Reed; openmama-dev@... Subject: Re: [Openmama-dev] Transport callbacks when a middleware bridge automatically reconnects a transport
Yep, the SR Labs TCP middleware does exactly as you suggest, in that there is a second disconnect call back when the reconnects have finally failed. We’ll add this note to the bridge wiki as well.
There is the platformInfo parameter in the callback which could be used to pass back extra info but it’s no where near ideal for this as it’s a void* - the use of this is historical where there has been a need to pass back middleware specific items, but this is not usable across middlewares in its current form.
I’m fully supportive of enhancing this area in a future release as long it there is a) a desire for it out there and b) a way we can implement it in a backward compatible manner.
Cheers, Glenn
From: Alireza Assadzadeh <Alireza.Assadzadeh@...>
Hi,
Glen and Reed, thank you for your responses.
Open (2) sounds good. Given the current (2.3.x) functionality of OpenMAMA and the importance of using a consistent/safe approach for current users, I also think option (2) is our best choice.
Option (2): (a) onDisconnect (b) onReconnect
For the Solace OpenMAMA Middleware Bridge, we will use Option (2) then.
I would like to also highlight and reconfirm that for option (2), in scenario we have “(c) if all reconnect attempts fail, at the time of the last reconnect failure, the provides a MAMA_TRANSPORT_DISCONNECT”. Therefore, in the reconnect failure scenario, there are two disconnect notifications provided to the application. Do you see any issues with generating the second onDisconnect back to back (without a matching onReconnect or onConnect)? Does the SR Labs TCP middleware also generate two onDisconnect notifications for the reconnect failure scenario?
I didn’t notice any requirements in the OpenMAMA codebase against generating the second onDisconnect for the reconnect failure scenario. If generating the second onDisconnect is ok, I was thinking we could populate additional information in the ‘cause’ and/or ‘platfromInfo’ for any application that is interested in realizing the difference between the two onDisconnect notifications types (which would be Middleware specific, since ‘cause’ does not have a predefined/standardized set of values).
Regarding future enhancements, if there is sufficient interest in the community about a separate state for Reconnecting, we could consider adding support for it in a future OpenMAMA release (for Middleware bridges that have the capability).
--Alireza
From: Alpert, Reed [mailto:reed.alpert@...]
Hi,
For us consistency between the bridges is the most important item.
Tick42/RMDS also uses the onDisconnect/OnReconnect model (and sends STALE status for each subscription).
Both Tick42 and Solace offer, via config, to re-establish each of the subscriptions, so our apps don’t do anything when we get an onDisconnect (except stop any publishing), and then wait for onReconnect and the following INITIALs.
It would be good to have a notice that a transport could not be reconnected and the bridge has closed the transport (both Solace and Tick42 have configurable limited retries). In that case the app needs to raise a support request to Operations.
It is the case that onQuality(STALE) followed by onQuality(OK) could accomplish the same thing in our case, as the app would simply wait, but keeping the bridge behavior the same makes for less moving parts.
Thanks,
Reed.
Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198 | M: 917.414.4613 | reed.alpert@...
Alternate Contact: CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...
From:openmama-dev-bounces@...
[mailto:openmama-dev-bounces@...]
On Behalf Of Glenn McClements
Hi Alireza,
Currently for the SR Labs TCP middleware, which is the closest in behaviour to Solace we do:
Option (2): (a) onDisconnect (b) onReconnect
So this would be the most consistent/safest options for current users (this will also trigger an onPossiblyStale for the subscriptions on that transport btw).
You’re right though that people may want to distinguish between a temporary disconnect and a permanent disconnect, in order to only perform the more drastic cleanup type behaviour when a permanent disconnect happens, but there currently isn’t a clean way to do this.
Your solution is analogous to PossiblyStale for the subscriptions, which goes to OK or Stale depending on the whether a message has been missed. We could have a Reconnecting state which would then go to Connected or Disconnected depending on outcome of the retry logic. At the moment I’d say this would be a nice to have for future consideration though as I don’t recall this coming up before from a customer request before.
We’ll update the bridge wiki with the above behaviour http://wiki.openmama.org/index.php/OpenMAMA_Bridge_Documentation
Apologies in the delay for getting back btw.
Cheers, Glenn
From: Alireza Assadzadeh <Alireza.Assadzadeh@...>
Hi Folks,
Some middleware bridges may have the capability to automatically reconnect to their messaging infrastructure after a connection failure, for example at the TCP/socket layer. In OpenMAMA C layer, there is the mamaTransportCB and the mamaTransportEvent enum to allow notification about different transport conditions from the middleware bridge to OpenMAMA layer and to the application. In MAMA C++, there is MamaTransportCallback which provides similar notification for a C++ application, for example using onConnect, onDisconnect, onReconnect, and onQuality. There are similar notification mechanisms for the application for other OpenMAMA supported language bindings such as Java and C#.
I was looking at what would be a commonly expected and accepted behaviour when the middleware bridge automatically reconnects the connection and was hoping to get your input.
Consider the case that a middleware bridge notices a connection failure on a previously established connection. The middleware bridge that is capable of automatically reconnecting then automatically starts a retry mechanism for a predefined number of attempts and may eventually either succeed or fail to reestablish the connection. A middleware that is not capable of automatically reconnecting would provide a disconnect event to the application.
For this scenario there are several conceivable options for the middleware bridge and OpenMAMA to provide notifications to the application:
One option is the following: (a) When connection is lost, provide a MAMA_TRANSPORT_QUALITY event. (b) If the connection is successfully reestablished, at the time it is reestablished, provide MAMA_TRANSPORT_RECONNECT event. (c) If all reconnect attempts fail, at the time of the last reconnect failure, provide a MAMA_TRANSPORT_DISCONNECT.
Another option is that for condition (a), provide a MAMA_TRANSPORT_DISCONNECT event (instead of MAMA_TRANSPORT_QUALITY).
Yet another option is that for condition (b), provide a MAMA_TRANSPORT_QUALITY event (instead of MAMA_TRANSPORT_RECONNECT). For this option (a) and (b) are differentiated by the application using different values for ‘cause’ in the callback and transport quality is changed accordingly.
Here are the above three options summarized using the C++ callback names as shorthand. There are other options, but I think these three illustrate the flexibility / interpretation and the need for elaborating in this area.
Option (1): (a) onQuality(cause=1) (b) onReconnect Option (2): (a) onDisconnect (b) onReconnect Option (3): (a) onQuality(cause=1) (b) onQuality(cause=0)
For option (1) there may also be an onQuality(cause=0) after the connection is reestablished if the transport has a marketdata subscription with recover gaps and new messaging arrive do not have gaps.
We had initially been thinking about implementing option (1) in the Solace OpenMAMA Middleware Bridge. One concern we had with using option (2) was that the onDisconnect may result in a typical application itself to clean up the transport and possibly take transport reconnect actions rather than allowing a middleware (that is capable of doing the automatic reconnect) to perform its reconnect attempts.
Another option is enhance the transport callback. For example, to provide a onReconnecting callback when a connection is lost and the middleware is in the state of “reconnecting” the lost connection. However, adding a new callback would require a new OpenMAMA version and may be a longer term possibility to think about.
It is valuable to provide a consistent and clear behaviour to the applications in this area, specially across different middleware bridge types. What is the expected behaviour and design of OpenMAMA for these notifications and what do other bridges do in these cases?
Regards,
--Alireza This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. |
|
|
|
Re: Transport callbacks when a middleware bridge automatically reconnects a transport
Alireza Assadzadeh <Alireza.Assadzadeh@...>
Glenn,
Thanks for your reply and confirmations.
Also it sounds good about updating the wiki in this area. If you need any additional input from my side, please let me know.
Regards
--Alireza
From: Glenn McClements [mailto:g.mcclements@...]
Sent: Tuesday, January 27, 2015 12:08 PM To: Alireza Assadzadeh; Alpert, Reed; openmama-dev@... Subject: Re: [Openmama-dev] Transport callbacks when a middleware bridge automatically reconnects a transport
Yep, the SR Labs TCP middleware does exactly as you suggest, in that there is a second disconnect call back when the reconnects have finally failed. We’ll add this note to the bridge wiki as well.
There is the platformInfo parameter in the callback which could be used to pass back extra info but it’s no where near ideal for this as it’s a void* - the use of this is historical where there has been a need to pass back middleware specific items, but this is not usable across middlewares in its current form.
I’m fully supportive of enhancing this area in a future release as long it there is a) a desire for it out there and b) a way we can implement it in a backward compatible manner.
Cheers, Glenn
From: Alireza Assadzadeh <Alireza.Assadzadeh@...>
Hi,
Glen and Reed, thank you for your responses.
Open (2) sounds good. Given the current (2.3.x) functionality of OpenMAMA and the importance of using a consistent/safe approach for current users, I also think option (2) is our best choice.
Option (2): (a) onDisconnect (b) onReconnect
For the Solace OpenMAMA Middleware Bridge, we will use Option (2) then.
I would like to also highlight and reconfirm that for option (2), in scenario we have “(c) if all reconnect attempts fail, at the time of the last reconnect failure, the provides a MAMA_TRANSPORT_DISCONNECT”. Therefore, in the reconnect failure scenario, there are two disconnect notifications provided to the application. Do you see any issues with generating the second onDisconnect back to back (without a matching onReconnect or onConnect)? Does the SR Labs TCP middleware also generate two onDisconnect notifications for the reconnect failure scenario?
I didn’t notice any requirements in the OpenMAMA codebase against generating the second onDisconnect for the reconnect failure scenario. If generating the second onDisconnect is ok, I was thinking we could populate additional information in the ‘cause’ and/or ‘platfromInfo’ for any application that is interested in realizing the difference between the two onDisconnect notifications types (which would be Middleware specific, since ‘cause’ does not have a predefined/standardized set of values).
Regarding future enhancements, if there is sufficient interest in the community about a separate state for Reconnecting, we could consider adding support for it in a future OpenMAMA release (for Middleware bridges that have the capability).
--Alireza
From: Alpert, Reed [mailto:reed.alpert@...]
Hi,
For us consistency between the bridges is the most important item.
Tick42/RMDS also uses the onDisconnect/OnReconnect model (and sends STALE status for each subscription).
Both Tick42 and Solace offer, via config, to re-establish each of the subscriptions, so our apps don’t do anything when we get an onDisconnect (except stop any publishing), and then wait for onReconnect and the following INITIALs.
It would be good to have a notice that a transport could not be reconnected and the bridge has closed the transport (both Solace and Tick42 have configurable limited retries). In that case the app needs to raise a support request to Operations.
It is the case that onQuality(STALE) followed by onQuality(OK) could accomplish the same thing in our case, as the app would simply wait, but keeping the bridge behavior the same makes for less moving parts.
Thanks,
Reed.
Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198 | M: 917.414.4613 | reed.alpert@...
Alternate Contact: CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...
From:openmama-dev-bounces@...
[mailto:openmama-dev-bounces@...]
On Behalf Of Glenn McClements
Hi Alireza,
Currently for the SR Labs TCP middleware, which is the closest in behaviour to Solace we do:
Option (2): (a) onDisconnect (b) onReconnect
So this would be the most consistent/safest options for current users (this will also trigger an onPossiblyStale for the subscriptions on that transport btw).
You’re right though that people may want to distinguish between a temporary disconnect and a permanent disconnect, in order to only perform the more drastic cleanup type behaviour when a permanent disconnect happens, but there currently isn’t a clean way to do this.
Your solution is analogous to PossiblyStale for the subscriptions, which goes to OK or Stale depending on the whether a message has been missed. We could have a Reconnecting state which would then go to Connected or Disconnected depending on outcome of the retry logic. At the moment I’d say this would be a nice to have for future consideration though as I don’t recall this coming up before from a customer request before.
We’ll update the bridge wiki with the above behaviour http://wiki.openmama.org/index.php/OpenMAMA_Bridge_Documentation
Apologies in the delay for getting back btw.
Cheers, Glenn
From: Alireza Assadzadeh <Alireza.Assadzadeh@...>
Hi Folks,
Some middleware bridges may have the capability to automatically reconnect to their messaging infrastructure after a connection failure, for example at the TCP/socket layer. In OpenMAMA C layer, there is the mamaTransportCB and the mamaTransportEvent enum to allow notification about different transport conditions from the middleware bridge to OpenMAMA layer and to the application. In MAMA C++, there is MamaTransportCallback which provides similar notification for a C++ application, for example using onConnect, onDisconnect, onReconnect, and onQuality. There are similar notification mechanisms for the application for other OpenMAMA supported language bindings such as Java and C#.
I was looking at what would be a commonly expected and accepted behaviour when the middleware bridge automatically reconnects the connection and was hoping to get your input.
Consider the case that a middleware bridge notices a connection failure on a previously established connection. The middleware bridge that is capable of automatically reconnecting then automatically starts a retry mechanism for a predefined number of attempts and may eventually either succeed or fail to reestablish the connection. A middleware that is not capable of automatically reconnecting would provide a disconnect event to the application.
For this scenario there are several conceivable options for the middleware bridge and OpenMAMA to provide notifications to the application:
One option is the following: (a) When connection is lost, provide a MAMA_TRANSPORT_QUALITY event. (b) If the connection is successfully reestablished, at the time it is reestablished, provide MAMA_TRANSPORT_RECONNECT event. (c) If all reconnect attempts fail, at the time of the last reconnect failure, provide a MAMA_TRANSPORT_DISCONNECT.
Another option is that for condition (a), provide a MAMA_TRANSPORT_DISCONNECT event (instead of MAMA_TRANSPORT_QUALITY).
Yet another option is that for condition (b), provide a MAMA_TRANSPORT_QUALITY event (instead of MAMA_TRANSPORT_RECONNECT). For this option (a) and (b) are differentiated by the application using different values for ‘cause’ in the callback and transport quality is changed accordingly.
Here are the above three options summarized using the C++ callback names as shorthand. There are other options, but I think these three illustrate the flexibility / interpretation and the need for elaborating in this area.
Option (1): (a) onQuality(cause=1) (b) onReconnect Option (2): (a) onDisconnect (b) onReconnect Option (3): (a) onQuality(cause=1) (b) onQuality(cause=0)
For option (1) there may also be an onQuality(cause=0) after the connection is reestablished if the transport has a marketdata subscription with recover gaps and new messaging arrive do not have gaps.
We had initially been thinking about implementing option (1) in the Solace OpenMAMA Middleware Bridge. One concern we had with using option (2) was that the onDisconnect may result in a typical application itself to clean up the transport and possibly take transport reconnect actions rather than allowing a middleware (that is capable of doing the automatic reconnect) to perform its reconnect attempts.
Another option is enhance the transport callback. For example, to provide a onReconnecting callback when a connection is lost and the middleware is in the state of “reconnecting” the lost connection. However, adding a new callback would require a new OpenMAMA version and may be a longer term possibility to think about.
It is valuable to provide a consistent and clear behaviour to the applications in this area, specially across different middleware bridge types. What is the expected behaviour and design of OpenMAMA for these notifications and what do other bridges do in these cases?
Regards,
--Alireza This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. |
|
|
|
Re: Notification for new subscriptions Mathias
Glenn McClements <g.mcclements@...>
Hi Mathias,
As Paul pointed out, what you would really want is DQPublisher for C#, but unfortunately there isn’t one at the moment. The reason for this is that that previously there hasn’t been a real demand as most C# applications have been on the client subscribing
side, not the publishing side.
It sounds like there are a least a few people now looking for one so I’d be interested in finding out if there are others out there looking the same and if anyone if willing to contribute code in this are?
Also to clarify:
The MamaPublisher “basic" publishing ie. without sequence numbers, initial images/recaps etc or any other market data/data quality type features. The equivalent class on the subscribing side is MamaBasicSubscription.
The MamaDQPublisher and associated classes have sequence number injection, callbacks when a client subscription is made etc. The equivalent class on the subscribing side is MamaSubscription.
Cheers,
Glenn
From: Paul Bradbury <paul.bradbury@...>
Date: Monday, 26 January 2015 16:20 To: "openmama-dev@..." <openmama-dev@...> Subject: Re: [Openmama-dev] Notification for new subscriptions From what I recall there, are no .net wrappers for the DQPublisher as yet (although somewhat unfairly there are in the Java codebase!). For me as a greenfield application, it was simpler to write in C++, but I think adding those wrappers wasn’t too big a deal as they were really just wrappers along the lines of the existing code for the normal publisher.
Paul.
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Kim Mathias
Hi,
Currently, I am trying to set up a publisher for market data with OpenMAMA in C#. I wonder if there is a way to receive a notifcation every time my publisher accepts a new subscription from a subscriber? Is there an event thrown that I can handle?
Also, I still don't completely understand the difference between a basic publisher and an advanced publisher. In the development guide, the latter is only mentioned but never described in detail (e.g. how to use it).
Best regards
Mathias No virus found in this message. |
|
|
|
Re: Transport callbacks when a middleware bridge automatically reconnects a transport
Glenn McClements <g.mcclements@...>
Yep, the SR Labs TCP middleware does exactly as you suggest, in that there is a second disconnect call back when the reconnects have finally failed. We’ll add this note to the bridge wiki as well.
There is the platformInfo parameter in the callback which
could be used to pass back extra info but it’s no where near ideal for this as it’s a void* - the use of this is historical where there has been a need to pass back middleware specific items, but this is not usable across middlewares in its current form.
I’m fully supportive of enhancing this area in a future release as long it there is a) a desire for it out there and b) a way we can implement it in a backward compatible manner.
Cheers,
Glenn
From: Alireza Assadzadeh <Alireza.Assadzadeh@...>
Date: Monday, 26 January 2015 21:22 To: "Alpert, Reed" <reed.alpert@...>, Glenn McClements <g.mcclements@...>, "openmama-dev@..." <openmama-dev@...> Subject: RE: [Openmama-dev] Transport callbacks when a middleware bridge automatically reconnects a transport Hi,
Glen and Reed, thank you for your responses.
Open (2) sounds good. Given the current (2.3.x) functionality of OpenMAMA and the importance of using a consistent/safe approach for current users, I also think option (2) is our best choice.
Option (2): (a) onDisconnect (b) onReconnect
For the Solace OpenMAMA Middleware Bridge, we will use Option (2) then.
I would like to also highlight and reconfirm that for option (2), in scenario we have “(c) if all reconnect attempts fail, at the time of the last reconnect failure, the provides a MAMA_TRANSPORT_DISCONNECT”. Therefore, in the reconnect failure scenario, there are two disconnect notifications provided to the application. Do you see any issues with generating the second onDisconnect back to back (without a matching onReconnect or onConnect)? Does the SR Labs TCP middleware also generate two onDisconnect notifications for the reconnect failure scenario?
I didn’t notice any requirements in the OpenMAMA codebase against generating the second onDisconnect for the reconnect failure scenario. If generating the second onDisconnect is ok, I was thinking we could populate additional information in the ‘cause’ and/or ‘platfromInfo’ for any application that is interested in realizing the difference between the two onDisconnect notifications types (which would be Middleware specific, since ‘cause’ does not have a predefined/standardized set of values).
Regarding future enhancements, if there is sufficient interest in the community about a separate state for Reconnecting, we could consider adding support for it in a future OpenMAMA release (for Middleware bridges that have the capability).
--Alireza
From: Alpert, Reed [mailto:reed.alpert@...]
Sent: Thursday, January 22, 2015 10:43 AM To: Glenn McClements; Alireza Assadzadeh; openmama-dev@... Subject: RE: [Openmama-dev] Transport callbacks when a middleware bridge automatically reconnects a transport
Hi,
For us consistency between the bridges is the most important item.
Tick42/RMDS also uses the onDisconnect/OnReconnect model (and sends STALE status for each subscription).
Both Tick42 and Solace offer, via config, to re-establish each of the subscriptions, so our apps don’t do anything when we get an onDisconnect (except stop any publishing), and then wait for onReconnect and the following INITIALs.
It would be good to have a notice that a transport could not be reconnected and the bridge has closed the transport (both Solace and Tick42 have configurable limited retries). In that case the app needs to raise a support request to Operations.
It is the case that onQuality(STALE) followed by onQuality(OK) could accomplish the same thing in our case, as the app would simply wait, but keeping the bridge behavior the same makes for less moving parts.
Thanks,
Reed.
Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198 | M: 917.414.4613 | reed.alpert@...
Alternate Contact: CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...
From:openmama-dev-bounces@...
[mailto:openmama-dev-bounces@...]
On Behalf Of Glenn McClements
Hi Alireza,
Currently for the SR Labs TCP middleware, which is the closest in behaviour to Solace we do:
Option (2): (a) onDisconnect (b) onReconnect
So this would be the most consistent/safest options for current users (this will also trigger an onPossiblyStale for the subscriptions on that transport btw).
You’re right though that people may want to distinguish between a temporary disconnect and a permanent disconnect, in order to only perform the more drastic cleanup type behaviour when a permanent disconnect happens, but there currently isn’t a clean way to do this.
Your solution is analogous to PossiblyStale for the subscriptions, which goes to OK or Stale depending on the whether a message has been missed. We could have a Reconnecting state which would then go to Connected or Disconnected depending on outcome of the retry logic. At the moment I’d say this would be a nice to have for future consideration though as I don’t recall this coming up before from a customer request before.
We’ll update the bridge wiki with the above behaviour http://wiki.openmama.org/index.php/OpenMAMA_Bridge_Documentation
Apologies in the delay for getting back btw.
Cheers, Glenn
From: Alireza Assadzadeh <Alireza.Assadzadeh@...>
Hi Folks,
Some middleware bridges may have the capability to automatically reconnect to their messaging infrastructure after a connection failure, for example at the TCP/socket layer. In OpenMAMA C layer, there is the mamaTransportCB and the mamaTransportEvent enum to allow notification about different transport conditions from the middleware bridge to OpenMAMA layer and to the application. In MAMA C++, there is MamaTransportCallback which provides similar notification for a C++ application, for example using onConnect, onDisconnect, onReconnect, and onQuality. There are similar notification mechanisms for the application for other OpenMAMA supported language bindings such as Java and C#.
I was looking at what would be a commonly expected and accepted behaviour when the middleware bridge automatically reconnects the connection and was hoping to get your input.
Consider the case that a middleware bridge notices a connection failure on a previously established connection. The middleware bridge that is capable of automatically reconnecting then automatically starts a retry mechanism for a predefined number of attempts and may eventually either succeed or fail to reestablish the connection. A middleware that is not capable of automatically reconnecting would provide a disconnect event to the application.
For this scenario there are several conceivable options for the middleware bridge and OpenMAMA to provide notifications to the application:
One option is the following: (a) When connection is lost, provide a MAMA_TRANSPORT_QUALITY event. (b) If the connection is successfully reestablished, at the time it is reestablished, provide MAMA_TRANSPORT_RECONNECT event. (c) If all reconnect attempts fail, at the time of the last reconnect failure, provide a MAMA_TRANSPORT_DISCONNECT.
Another option is that for condition (a), provide a MAMA_TRANSPORT_DISCONNECT event (instead of MAMA_TRANSPORT_QUALITY).
Yet another option is that for condition (b), provide a MAMA_TRANSPORT_QUALITY event (instead of MAMA_TRANSPORT_RECONNECT). For this option (a) and (b) are differentiated by the application using different values for ‘cause’ in the callback and transport quality is changed accordingly.
Here are the above three options summarized using the C++ callback names as shorthand. There are other options, but I think these three illustrate the flexibility / interpretation and the need for elaborating in this area.
Option (1): (a) onQuality(cause=1) (b) onReconnect Option (2): (a) onDisconnect (b) onReconnect Option (3): (a) onQuality(cause=1) (b) onQuality(cause=0)
For option (1) there may also be an onQuality(cause=0) after the connection is reestablished if the transport has a marketdata subscription with recover gaps and new messaging arrive do not have gaps.
We had initially been thinking about implementing option (1) in the Solace OpenMAMA Middleware Bridge. One concern we had with using option (2) was that the onDisconnect may result in a typical application itself to clean up the transport and possibly take transport reconnect actions rather than allowing a middleware (that is capable of doing the automatic reconnect) to perform its reconnect attempts.
Another option is enhance the transport callback. For example, to provide a onReconnecting callback when a connection is lost and the middleware is in the state of “reconnecting” the lost connection. However, adding a new callback would require a new OpenMAMA version and may be a longer term possibility to think about.
It is valuable to provide a consistent and clear behaviour to the applications in this area, specially across different middleware bridge types. What is the expected behaviour and design of OpenMAMA for these notifications and what do other bridges do in these cases?
Regards,
--Alireza This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. |
|
|
|
Re: Transport callbacks when a middleware bridge automatically reconnects a transport
Alireza Assadzadeh <Alireza.Assadzadeh@...>
Hi,
Glen and Reed, thank you for your responses.
Open (2) sounds good. Given the current (2.3.x) functionality of OpenMAMA and the importance of using a consistent/safe approach for current users, I also think option (2) is our best choice.
Option (2): (a) onDisconnect (b) onReconnect
For the Solace OpenMAMA Middleware Bridge, we will use Option (2) then.
I would like to also highlight and reconfirm that for option (2), in scenario we have “(c) if all reconnect attempts fail, at the time of the last reconnect failure, the provides a MAMA_TRANSPORT_DISCONNECT”. Therefore, in the reconnect failure scenario, there are two disconnect notifications provided to the application. Do you see any issues with generating the second onDisconnect back to back (without a matching onReconnect or onConnect)? Does the SR Labs TCP middleware also generate two onDisconnect notifications for the reconnect failure scenario?
I didn’t notice any requirements in the OpenMAMA codebase against generating the second onDisconnect for the reconnect failure scenario. If generating the second onDisconnect is ok, I was thinking we could populate additional information in the ‘cause’ and/or ‘platfromInfo’ for any application that is interested in realizing the difference between the two onDisconnect notifications types (which would be Middleware specific, since ‘cause’ does not have a predefined/standardized set of values).
Regarding future enhancements, if there is sufficient interest in the community about a separate state for Reconnecting, we could consider adding support for it in a future OpenMAMA release (for Middleware bridges that have the capability).
--Alireza
From: Alpert, Reed [mailto:reed.alpert@...]
Sent: Thursday, January 22, 2015 10:43 AM To: Glenn McClements; Alireza Assadzadeh; openmama-dev@... Subject: RE: [Openmama-dev] Transport callbacks when a middleware bridge automatically reconnects a transport
Hi,
For us consistency between the bridges is the most important item.
Tick42/RMDS also uses the onDisconnect/OnReconnect model (and sends STALE status for each subscription).
Both Tick42 and Solace offer, via config, to re-establish each of the subscriptions, so our apps don’t do anything when we get an onDisconnect (except stop any publishing), and then wait for onReconnect and the following INITIALs.
It would be good to have a notice that a transport could not be reconnected and the bridge has closed the transport (both Solace and Tick42 have configurable limited retries). In that case the app needs to raise a support request to Operations.
It is the case that onQuality(STALE) followed by onQuality(OK) could accomplish the same thing in our case, as the app would simply wait, but keeping the bridge behavior the same makes for less moving parts.
Thanks,
Reed.
Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198 | M: 917.414.4613 | reed.alpert@...
Alternate Contact: CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Glenn McClements
Hi Alireza,
Currently for the SR Labs TCP middleware, which is the closest in behaviour to Solace we do:
Option (2): (a) onDisconnect (b) onReconnect
So this would be the most consistent/safest options for current users (this will also trigger an onPossiblyStale for the subscriptions on that transport btw).
You’re right though that people may want to distinguish between a temporary disconnect and a permanent disconnect, in order to only perform the more drastic cleanup type behaviour when a permanent disconnect happens, but there currently isn’t a clean way to do this.
Your solution is analogous to PossiblyStale for the subscriptions, which goes to OK or Stale depending on the whether a message has been missed. We could have a Reconnecting state which would then go to Connected or Disconnected depending on outcome of the retry logic. At the moment I’d say this would be a nice to have for future consideration though as I don’t recall this coming up before from a customer request before.
We’ll update the bridge wiki with the above behaviour http://wiki.openmama.org/index.php/OpenMAMA_Bridge_Documentation
Apologies in the delay for getting back btw.
Cheers, Glenn
From: Alireza Assadzadeh <Alireza.Assadzadeh@...>
Hi Folks,
Some middleware bridges may have the capability to automatically reconnect to their messaging infrastructure after a connection failure, for example at the TCP/socket layer. In OpenMAMA C layer, there is the mamaTransportCB and the mamaTransportEvent enum to allow notification about different transport conditions from the middleware bridge to OpenMAMA layer and to the application. In MAMA C++, there is MamaTransportCallback which provides similar notification for a C++ application, for example using onConnect, onDisconnect, onReconnect, and onQuality. There are similar notification mechanisms for the application for other OpenMAMA supported language bindings such as Java and C#.
I was looking at what would be a commonly expected and accepted behaviour when the middleware bridge automatically reconnects the connection and was hoping to get your input.
Consider the case that a middleware bridge notices a connection failure on a previously established connection. The middleware bridge that is capable of automatically reconnecting then automatically starts a retry mechanism for a predefined number of attempts and may eventually either succeed or fail to reestablish the connection. A middleware that is not capable of automatically reconnecting would provide a disconnect event to the application.
For this scenario there are several conceivable options for the middleware bridge and OpenMAMA to provide notifications to the application:
One option is the following: (a) When connection is lost, provide a MAMA_TRANSPORT_QUALITY event. (b) If the connection is successfully reestablished, at the time it is reestablished, provide MAMA_TRANSPORT_RECONNECT event. (c) If all reconnect attempts fail, at the time of the last reconnect failure, provide a MAMA_TRANSPORT_DISCONNECT.
Another option is that for condition (a), provide a MAMA_TRANSPORT_DISCONNECT event (instead of MAMA_TRANSPORT_QUALITY).
Yet another option is that for condition (b), provide a MAMA_TRANSPORT_QUALITY event (instead of MAMA_TRANSPORT_RECONNECT). For this option (a) and (b) are differentiated by the application using different values for ‘cause’ in the callback and transport quality is changed accordingly.
Here are the above three options summarized using the C++ callback names as shorthand. There are other options, but I think these three illustrate the flexibility / interpretation and the need for elaborating in this area.
Option (1): (a) onQuality(cause=1) (b) onReconnect Option (2): (a) onDisconnect (b) onReconnect Option (3): (a) onQuality(cause=1) (b) onQuality(cause=0)
For option (1) there may also be an onQuality(cause=0) after the connection is reestablished if the transport has a marketdata subscription with recover gaps and new messaging arrive do not have gaps.
We had initially been thinking about implementing option (1) in the Solace OpenMAMA Middleware Bridge. One concern we had with using option (2) was that the onDisconnect may result in a typical application itself to clean up the transport and possibly take transport reconnect actions rather than allowing a middleware (that is capable of doing the automatic reconnect) to perform its reconnect attempts.
Another option is enhance the transport callback. For example, to provide a onReconnecting callback when a connection is lost and the middleware is in the state of “reconnecting” the lost connection. However, adding a new callback would require a new OpenMAMA version and may be a longer term possibility to think about.
It is valuable to provide a consistent and clear behaviour to the applications in this area, specially across different middleware bridge types. What is the expected behaviour and design of OpenMAMA for these notifications and what do other bridges do in these cases?
Regards,
--Alireza This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. |
|
|
|
Re: Notification for new subscriptions
Paul Bradbury
From what I recall there, are no .net wrappers for the DQPublisher as yet (although somewhat unfairly there are in the Java codebase!). For me as a greenfield application, it was simpler to write in C++, but I think adding those wrappers wasn’t too big a deal as they were really just wrappers along the lines of the existing code for the normal publisher.
Paul.
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Kim Mathias
Sent: 26 January 2015 16:03 To: openmama-dev@... Subject: [Openmama-dev] Notification for new subscriptions
Hi,
Currently, I am trying to set up a publisher for market data with OpenMAMA in C#. I wonder if there is a way to receive a notifcation every time my publisher accepts a new subscription from a subscriber? Is there an event thrown that I can handle?
Also, I still don't completely understand the difference between a basic publisher and an advanced publisher. In the development guide, the latter is only mentioned but never described in detail (e.g. how to use it).
Best regards
Mathias No virus found in this message. |
|
|
|
Notification for new subscriptions
Mathias Kim
Hi,
Currently, I am trying to set up a publisher for market data with OpenMAMA in C#. I wonder if there is a way to receive a notifcation every time my publisher accepts a new subscription from a subscriber? Is there an event thrown that I can handle?
Also, I still don't completely understand the difference between a basic publisher and an advanced publisher. In the development guide, the latter is only mentioned but never described in detail (e.g. how to use it).
Best regards
Mathias |
|
|
|
Re: Transport callbacks when a middleware bridge automatically reconnects a transport
Alpert, Reed <reed.alpert@...>
Hi,
For us consistency between the bridges is the most important item.
Tick42/RMDS also uses the onDisconnect/OnReconnect model (and sends STALE status for each subscription).
Both Tick42 and Solace offer, via config, to re-establish each of the subscriptions, so our apps don’t do anything when we get an onDisconnect (except stop any publishing), and then wait for onReconnect and the following INITIALs.
It would be good to have a notice that a transport could not be reconnected and the bridge has closed the transport (both Solace and Tick42 have configurable limited retries). In that case the app needs to raise a support request to Operations.
It is the case that onQuality(STALE) followed by onQuality(OK) could accomplish the same thing in our case, as the app would simply wait, but keeping the bridge behavior the same makes for less moving parts.
Thanks,
Reed.
Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198 | M: 917.414.4613 | reed.alpert@...
Alternate Contact: CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Glenn McClements
Sent: Thursday, January 22, 2015 9:23 AM To: Alireza Assadzadeh; openmama-dev@... Subject: Re: [Openmama-dev] Transport callbacks when a middleware bridge automatically reconnects a transport
Hi Alireza,
Currently for the SR Labs TCP middleware, which is the closest in behaviour to Solace we do:
Option (2): (a) onDisconnect (b) onReconnect
So this would be the most consistent/safest options for current users (this will also trigger an onPossiblyStale for the subscriptions on that transport btw).
You’re right though that people may want to distinguish between a temporary disconnect and a permanent disconnect, in order to only perform the more drastic cleanup type behaviour when a permanent disconnect happens, but there currently isn’t a clean way to do this.
Your solution is analogous to PossiblyStale for the subscriptions, which goes to OK or Stale depending on the whether a message has been missed. We could have a Reconnecting state which would then go to Connected or Disconnected depending on outcome of the retry logic. At the moment I’d say this would be a nice to have for future consideration though as I don’t recall this coming up before from a customer request before.
We’ll update the bridge wiki with the above behaviour http://wiki.openmama.org/index.php/OpenMAMA_Bridge_Documentation
Apologies in the delay for getting back btw.
Cheers, Glenn
From: Alireza Assadzadeh <Alireza.Assadzadeh@...>
Hi Folks,
Some middleware bridges may have the capability to automatically reconnect to their messaging infrastructure after a connection failure, for example at the TCP/socket layer. In OpenMAMA C layer, there is the mamaTransportCB and the mamaTransportEvent enum to allow notification about different transport conditions from the middleware bridge to OpenMAMA layer and to the application. In MAMA C++, there is MamaTransportCallback which provides similar notification for a C++ application, for example using onConnect, onDisconnect, onReconnect, and onQuality. There are similar notification mechanisms for the application for other OpenMAMA supported language bindings such as Java and C#.
I was looking at what would be a commonly expected and accepted behaviour when the middleware bridge automatically reconnects the connection and was hoping to get your input.
Consider the case that a middleware bridge notices a connection failure on a previously established connection. The middleware bridge that is capable of automatically reconnecting then automatically starts a retry mechanism for a predefined number of attempts and may eventually either succeed or fail to reestablish the connection. A middleware that is not capable of automatically reconnecting would provide a disconnect event to the application.
For this scenario there are several conceivable options for the middleware bridge and OpenMAMA to provide notifications to the application:
One option is the following: (a) When connection is lost, provide a MAMA_TRANSPORT_QUALITY event. (b) If the connection is successfully reestablished, at the time it is reestablished, provide MAMA_TRANSPORT_RECONNECT event. (c) If all reconnect attempts fail, at the time of the last reconnect failure, provide a MAMA_TRANSPORT_DISCONNECT.
Another option is that for condition (a), provide a MAMA_TRANSPORT_DISCONNECT event (instead of MAMA_TRANSPORT_QUALITY).
Yet another option is that for condition (b), provide a MAMA_TRANSPORT_QUALITY event (instead of MAMA_TRANSPORT_RECONNECT). For this option (a) and (b) are differentiated by the application using different values for ‘cause’ in the callback and transport quality is changed accordingly.
Here are the above three options summarized using the C++ callback names as shorthand. There are other options, but I think these three illustrate the flexibility / interpretation and the need for elaborating in this area.
Option (1): (a) onQuality(cause=1) (b) onReconnect Option (2): (a) onDisconnect (b) onReconnect Option (3): (a) onQuality(cause=1) (b) onQuality(cause=0)
For option (1) there may also be an onQuality(cause=0) after the connection is reestablished if the transport has a marketdata subscription with recover gaps and new messaging arrive do not have gaps.
We had initially been thinking about implementing option (1) in the Solace OpenMAMA Middleware Bridge. One concern we had with using option (2) was that the onDisconnect may result in a typical application itself to clean up the transport and possibly take transport reconnect actions rather than allowing a middleware (that is capable of doing the automatic reconnect) to perform its reconnect attempts.
Another option is enhance the transport callback. For example, to provide a onReconnecting callback when a connection is lost and the middleware is in the state of “reconnecting” the lost connection. However, adding a new callback would require a new OpenMAMA version and may be a longer term possibility to think about.
It is valuable to provide a consistent and clear behaviour to the applications in this area, specially across different middleware bridge types. What is the expected behaviour and design of OpenMAMA for these notifications and what do other bridges do in these cases?
Regards,
--Alireza This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. |
|
|
|
Re: Transport callbacks when a middleware bridge automatically reconnects a transport
Glenn McClements <g.mcclements@...>
Hi Alireza,
Currently for the SR Labs TCP middleware, which is the closest in behaviour to Solace we do:
Option (2): (a) onDisconnect (b) onReconnect So this would be the most consistent/safest options for current users (this will also trigger an onPossiblyStale for the subscriptions on that transport btw).
You’re right though that people may want to distinguish between a temporary disconnect and a permanent disconnect, in order to only perform the more drastic cleanup type behaviour when a permanent disconnect happens, but there
currently isn’t a clean way to do this.
Your solution is analogous to PossiblyStale for the subscriptions, which goes to OK or Stale depending on the whether a message has been missed. We could have a Reconnecting state which would then go to Connected or Disconnected
depending on outcome of the retry logic. At the moment I’d say this would be a nice to have for future consideration though as I don’t recall this coming up before from a customer request before.
We’ll update the bridge wiki with the above behaviour http://wiki.openmama.org/index.php/OpenMAMA_Bridge_Documentation
Apologies in the delay for getting back btw.
Cheers,
Glenn
From: Alireza Assadzadeh <Alireza.Assadzadeh@...>
Date: Thursday, 15 January 2015 22:54 To: "openmama-dev@..." <openmama-dev@...> Subject: [Openmama-dev] Transport callbacks when a middleware bridge automatically reconnects a transport Hi Folks,
Some middleware bridges may have the capability to automatically reconnect to their messaging infrastructure after a connection failure, for example at the TCP/socket layer. In OpenMAMA C layer, there is the mamaTransportCB and the mamaTransportEvent enum to allow notification about different transport conditions from the middleware bridge to OpenMAMA layer and to the application. In MAMA C++, there is MamaTransportCallback which provides similar notification for a C++ application, for example using onConnect, onDisconnect, onReconnect, and onQuality. There are similar notification mechanisms for the application for other OpenMAMA supported language bindings such as Java and C#.
I was looking at what would be a commonly expected and accepted behaviour when the middleware bridge automatically reconnects the connection and was hoping to get your input.
Consider the case that a middleware bridge notices a connection failure on a previously established connection. The middleware bridge that is capable of automatically reconnecting then automatically starts a retry mechanism for a predefined number of attempts and may eventually either succeed or fail to reestablish the connection. A middleware that is not capable of automatically reconnecting would provide a disconnect event to the application.
For this scenario there are several conceivable options for the middleware bridge and OpenMAMA to provide notifications to the application:
One option is the following: (a) When connection is lost, provide a MAMA_TRANSPORT_QUALITY event. (b) If the connection is successfully reestablished, at the time it is reestablished, provide MAMA_TRANSPORT_RECONNECT event. (c) If all reconnect attempts fail, at the time of the last reconnect failure, provide a MAMA_TRANSPORT_DISCONNECT.
Another option is that for condition (a), provide a MAMA_TRANSPORT_DISCONNECT event (instead of MAMA_TRANSPORT_QUALITY).
Yet another option is that for condition (b), provide a MAMA_TRANSPORT_QUALITY event (instead of MAMA_TRANSPORT_RECONNECT). For this option (a) and (b) are differentiated by the application using different values for ‘cause’ in the callback and transport quality is changed accordingly.
Here are the above three options summarized using the C++ callback names as shorthand. There are other options, but I think these three illustrate the flexibility / interpretation and the need for elaborating in this area.
Option (1): (a) onQuality(cause=1) (b) onReconnect Option (2): (a) onDisconnect (b) onReconnect Option (3): (a) onQuality(cause=1) (b) onQuality(cause=0)
For option (1) there may also be an onQuality(cause=0) after the connection is reestablished if the transport has a marketdata subscription with recover gaps and new messaging arrive do not have gaps.
We had initially been thinking about implementing option (1) in the Solace OpenMAMA Middleware Bridge. One concern we had with using option (2) was that the onDisconnect may result in a typical application itself to clean up the transport and possibly take transport reconnect actions rather than allowing a middleware (that is capable of doing the automatic reconnect) to perform its reconnect attempts.
Another option is enhance the transport callback. For example, to provide a onReconnecting callback when a connection is lost and the middleware is in the state of “reconnecting” the lost connection. However, adding a new callback would require a new OpenMAMA version and may be a longer term possibility to think about.
It is valuable to provide a consistent and clear behaviour to the applications in this area, specially across different middleware bridge types. What is the expected behaviour and design of OpenMAMA for these notifications and what do other bridges do in these cases?
Regards,
--Alireza |
|
|