Subscription onDestroy Callback


Sam Wilson <Sam.Wilson@...>
 

Hey everyone,

I spoke quickly with Damien about this on IRC, but I thought I should
raise the question with the community at large.

What thread should the subscription's onDestroy callback be called from?
We recently switched from calling it on a thread controlled by the
bridge to enqueuing it on the subscription's queue, but that seems to
cause a lot of trouble for the sample applications.

Section 9 of the OpenMAMA Developer's Guide for C leaves out the
onDestroy callback.

Thanks,
Sam


Alpert, Reed <reed.alpert@...>
 

Hi,

 

Does the onDestroy() guarantee that no more callbacks will be made for that subscription?

Similar to Reuters completion event.

To guarantee this it seems it must be posted as an event on the sub queue, and no more sent after that.

 

For destroy/create use case:

sub->destroy();

wait for onDestroy();

sub->create(>..);

 

What issues did the sample apps have?

 

Thanks,

 

Reed.

 

Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198  | M: 917.414.4613 | reed.alpert@...

Alternate Contact:  CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...

 

 

-----Original Message-----
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Sam Wilson
Sent: Wednesday, February 18, 2015 3:05 PM
To: openmama-dev@...
Subject: [Openmama-dev] Subscription onDestroy Callback

 

Hey everyone,

 

I spoke quickly with Damien about this on IRC, but I thought I should raise the question with the community at large.

 

What thread should the subscription's onDestroy callback be called from?

We recently switched from calling it on a thread controlled by the bridge to enqueuing it on the subscription's queue, but that seems to cause a lot of trouble for the sample applications.

 

Section 9 of the OpenMAMA Developer's Guide for C leaves out the onDestroy callback.

 

Thanks,

Sam

_______________________________________________

Openmama-dev mailing list

Openmama-dev@...

https://lists.openmama.org/mailman/listinfo/openmama-dev

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.


Sam Wilson <Sam.Wilson@...>
 

Hey Reed,

It does seem like onDestroy is intended to be used that way. When the bridge calls onDestroy, it causes OpenMAMA to switch the subscription's state from any of the "ING" states to the "ED" states, which lets the mama subscription be reused.

If you enqueue the onDestroy, mamaconsumer_v2 will hang while it is cleaning up. It stops the dispatcher with mama_stop, then waits for all the onDestroy events in consumerShutdown. If the dispatcher is stopped, no queued events can be delivered, so no onDestroy calls are made.

Cheers,
Sam


On 15-02-20 12:34 PM, Alpert, Reed wrote:

Hi,

 

Does the onDestroy() guarantee that no more callbacks will be made for that subscription?

Similar to Reuters completion event.

To guarantee this it seems it must be posted as an event on the sub queue, and no more sent after that.

 

For destroy/create use case:

sub->destroy();

wait for onDestroy();

sub->create(>..);

 

What issues did the sample apps have?

 

Thanks,

 

Reed.

 

Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198  | M: 917.414.4613 | reed.alpert@...

Alternate Contact:  CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...

 

 

-----Original Message-----
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Sam Wilson
Sent: Wednesday, February 18, 2015 3:05 PM
To: openmama-dev@...
Subject: [Openmama-dev] Subscription onDestroy Callback

 

Hey everyone,

 

I spoke quickly with Damien about this on IRC, but I thought I should raise the question with the community at large.

 

What thread should the subscription's onDestroy callback be called from?

We recently switched from calling it on a thread controlled by the bridge to enqueuing it on the subscription's queue, but that seems to cause a lot of trouble for the sample applications.

 

Section 9 of the OpenMAMA Developer's Guide for C leaves out the onDestroy callback.

 

Thanks,

Sam

_______________________________________________

Openmama-dev mailing list

Openmama-dev@...

https://lists.openmama.org/mailman/listinfo/openmama-dev

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.