Re: Error handling in market data subscription activation and error notification to application
Gary Molloy <g.molloy@...>
Thanks for your email.
I think that you have touched upon 2 issues here:
1. Synchronous Fails – if the create fails within the mamaSubscription_initialize() function it should be handled at this point. We should probably add in a return code and check what is being passed back from the call to self->mBridgeImpl->bridgeMamaSubscriptionCreate() where we could then invoked the onError() callback and stop the creation of the subscription continuing (and prevent onCreate() from being invoked). Some things that may need consideration:
a. Return codes – would the common set of MAMA return codes cover this or would they require expanding?
b. Threading - this will cause the onError() to be invoked from the default thread as opposed to the subscription thread. However this may not be a problem as the subscription will not be active…
2. Asynchronous Fails – I agree with you that mamaSubscription_processErr() is the correct function to use here. We have used this previously for in-house bridges for the same scenario. There is a transport function, mamaTransport_getDeactivateSubscriptionOnError(), that can be used to determine whether or not to deactivate the subscription on an error. A few additional things to consider also:
a. These events must be fired from the correct queue by the middleware bridge.
b. There is an issue with the mamaSubscription_processErr() function in that it always sends out a timeout with status ok. Again may need to look at the available return codes?
Would you agree with this take on your proposed solution(s)?
Should there be anything else to consider?
Gary Molloy – SR Labs
Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD
Tel: +44 28 9099 7580 Ext 3397
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alireza Assadzadeh
Sent: 09 December 2014 19:21
Subject: [Openmama-dev] Error handling in market data subscription activation and error notification to application
I have noticed that in Mama C subscription, if a market data subscription activation callback (i.e. createAction) fails the error is not propagated in Mama subscription layer to the application through the onError user callback for the subscription. For example, a throttled market data subscription may fail to activate due to Middleware Bridge create subscription failure.
Specifically for the Middleware Bridge failure case, looking at mamaSubscriptionImpl_completeMarketDataInitialisation, the call to mamaSubscription_initialize may have failed for example in birdgeMamaSubscriptionCreate call. The return code is not examined in the Mama Subscription and the subscription is always transitioned to activated state and the onCreate user callback is called. The onCreate user callback is called because the subscription creation (activation) is completed from the creation throttle.
This seems to be the design intent and there is no expectation that the Mama subscription would be calling the onError user callback in such failure cases. Can you please confirm and/or let me know your opinion on this?
Assuming this is the design intent, I think in the Middleware Bridge create subscription failure case, it follows that it is the responsibility of Middleware Bridge to notify the Mama C layer and the application about such errors asynchronously (beyond the function return status code for birdgeMamaSubscriptionCreate). The Middleware Bridge can provide the error notification through a subscription queue event error callback which will then perform the Mama subscription deactivation (optionally) and the call to the user onError callback. In other words, the Middleware Bridge may enqueue an event for mamaSubscription_processErr or a similar callback of its own to deactivate the Mama subscription (optionally) and call the user onError callback.
Note that there are cases where the Middleware Bridge may determine immediately in the bridge subscription create call that it is going to fail the subscription create call. There are also other cases where the Middleware Bridge (depending on its capabilities) may determine at later point in time, in an asynchronously fashion, that the Middleware Bridge subscription creation process encountered an error subsequently. So, for such cases, the Middleware Bridge may already have a mechanism in place to deactivate the Mama subscription and call the user onError callback.