Hi Folks,

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.

Regards,

--Alireza

Hi Alireza,

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?

[AA:] For the MW Bridge error conditions, I think the MAMA_STATUS_PLATFORM_ERROR in conjunction with mamaSubscription_getPlatformError should be fine. I think we need to check any additional error cases that are not from the MW-Bridge and see if the existing codes properly cover the failure case. Overall, there may be value in providing more specific or additional mama_status codes.

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…

[AA:] This seems ok to me, since also the onCreate() was called from the same thread and also subscription is not active (as you pointed out).

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?

[AA:] Agreed, I noticed that issue too with mamaSubscription_processErr(). I think the status code and platform error need to be changed to provide other errors that may occur.

Would you agree with this take on your proposed solution(s)?

[AA:] Yes. that sounds good to me.

Specially for the synchronous fail, I believe it is a better approach for the Mama layer to examine error conditions and call onError versus onCreate. This helps in providing a common error notification for the sync case to the application independent of the various MW-Bridge implementations.

Should there be anything else to consider?

[AA:] Other items that come to mind

a)      I am wondering about other cases that constitute a subscription activation failure. We have covered the MW Bridge bridgeMamaSubscription_create case here. There is the case of the subscription request for initial (if requires initial is set) failing which may fail in the MW-Bridge mamaPublisher_sendFromInboxByIndex. So, we need to examine other failure cases and determine for each case if it should result in the subscription activation failure and invoking onError.

b)      Backward compatibility for changing the synchronous failure notification mechanism also needs some thought. For synchronous failure, since OpenMAMA 2.3.1 does not provide the error notification of MW-Bridge errors, should the MW-Bridge provide the error notification to the application itself to work around this? If so, then when OpenMAMA new version provides the notification to the application, then the MW-Bridge should not anymore (to avoid having the onError() callback called twice).

Thanks,

Gary

Hi Folks,

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.

Regards,

--Alireza

Hi Gary,

Thanks a lot for your response on this. Your suggestions sound good.

Please see my comments to your mail inline marked with [AA:].

--Alireza