subscription msg queueing question


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

Hi,

 

The pdf dev guide says to only destroy a subscription from the same thread as the onMsg callbacks, or use destoryEx, which puts the destroy request on the subscription’s queue.

 

The Tick42 bridge (and maybe others) send the sub msgs back in a thread that is not the same as the one that dequeues from the sub’s queue.

In this case the destoryEx does not protect against a cotemporal onMsg and onDestroy callback.

 

Does the Wombat bridge queue sub msgs so that this strategy works to prevent onMsg and onDestroy from colliding ?

 

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@...

 

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 (collectively, "JPMC"). 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. 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. Although this transmission and any attachments are believed to be free of 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 JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.


Frank Quinn <f.quinn@...>
 

Hi Reed,

Preventing dereference of trashed memory certainly one of the benefits. MAMA in general will try and keep context local to a single thread where possible though to avoid having to lock in the interest of performance. I'm not sure what exactly you're doing though... When you say;

"The Tick42 bridge (and maybe others) send the sub msgs back in a thread that is not the same as the one that dequeues from the sub’s queue."

What are you defining as "the sub msgs" and where / what are you sending them to? A thread vs function diagram of your bridge would help if you have one too.

Cheers,
Frank

----- Reply message -----
From: "Alpert, Reed" <reed.alpert@...>
To: "openmama-dev@..." <openmama-dev@...>
Subject: [Openmama-dev] subscription msg queueing question
Date: Tue, May 19, 2015 19:50

Hi,

 

The pdf dev guide says to only destroy a subscription from the same thread as the onMsg callbacks, or use destoryEx, which puts the destroy request on the subscription’s queue.

 

The Tick42 bridge (and maybe others) send the sub msgs back in a thread that is not the same as the one that dequeues from the sub’s queue.

In this case the destoryEx does not protect against a cotemporal onMsg and onDestroy callback.

 

Does the Wombat bridge queue sub msgs so that this strategy works to prevent onMsg and onDestroy from colliding ?

 

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@...

 

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 (collectively, "JPMC"). 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. 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. Although this transmission and any attachments are believed to be free of 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 JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.