Subscription Create Behaviour


Slade, Michael J
 

Hi OpenMAMA Dev,

 

I wanted to clarify the expected behavior surrounding creation of subscriptions during application startup – should subscription activations always be executed by the thread dispatching events off the throttle queue?

 

Taking mamalistenc as an example, subscriptions can be created before we start dispatching on the default event queue. If the throttle rate is non-zero, the subscriptions’ activations are added to the throttle queue after the set interval has expired, but will not be executed until we start dispatching on the queue when we call mama_start.

 

The other behavior we see is if the throttle is disabled (the rate is set to <=0). The subscriptions’ activations are executed immediately on the calling thread – ignoring the queue - before the mama_start call due to the below code snippet. This results in the subscription being created on the transport and messages being received from the middleware before the mama_start call. Is this expected/allowed behavior?

 

Throttle.c:

if (self->mRate <= 0.0)

{

    /* throttle is not in use, execute immediately */

    mama_log (MAMA_LOG_LEVEL_FINEST, "wombatThrottle_dispatch (): "

              "no throttle; triggering action.");

    actionCb (closure1, closure2);

}

 

Thanks in advance,

Mike

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, malicious content and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.


Frank Quinn
 

Hi Mike,

 

Subscription activations may be created upfront before mama_start if not using the throttle yes.

 

The behaviour you have identified is similar to behaviour outlined in the OpenMAMA Developer’s guide in the MAMA Subscription Callbacks section where it is possible to receive an onMsg before the onCreate has even been fired. It’s the same sort of principle in both cases where the thread performing the setup differs from the thread performing the dispatch. Note I expect the behaviour you have observed will only happen if you’re (quite rightly) not using the default queue for your subscriptions.

 

If you want to prevent this behaviour, adding your own MAMA Queue event to initialized all unthrottled subscriptions when the default queue unblocks could be an option.

 

Cheers,

Frank

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Slade, Michael J via lists.openmama.org
Sent: 17 May 2021 11:02
To: openmama-dev@...
Subject: [Openmama-dev] Subscription Create Behaviour

 

Hi OpenMAMA Dev,

 

I wanted to clarify the expected behavior surrounding creation of subscriptions during application startup – should subscription activations always be executed by the thread dispatching events off the throttle queue?

 

Taking mamalistenc as an example, subscriptions can be created before we start dispatching on the default event queue. If the throttle rate is non-zero, the subscriptions’ activations are added to the throttle queue after the set interval has expired, but will not be executed until we start dispatching on the queue when we call mama_start.

 

The other behavior we see is if the throttle is disabled (the rate is set to <=0). The subscriptions’ activations are executed immediately on the calling thread – ignoring the queue - before the mama_start call due to the below code snippet. This results in the subscription being created on the transport and messages being received from the middleware before the mama_start call. Is this expected/allowed behavior?

 

Throttle.c:

if (self->mRate <= 0.0)

{

    /* throttle is not in use, execute immediately */

    mama_log (MAMA_LOG_LEVEL_FINEST, "wombatThrottle_dispatch (): "

              "no throttle; triggering action.");

    actionCb (closure1, closure2);

}

 

Thanks in advance,

Mike

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, malicious content and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.