Alireza Assadzadeh <Alireza.Assadzadeh@...>
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?