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. 

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

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. 

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

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. 

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

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 

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).

Regards,

--Alireza

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 

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).

Regards,

--Alireza