Hi,

Testing with OM 2.4.1.

If a C++/MamaPublisher is not destroyed before the C++/MamaTransport is destroyed, then the C/mamaTransport will notify each C/mamaPublisher that the transport is going away, and the mamaPublisher will call destroy on itself. This triggers the onDestroy callbacks, which vector up to the C++ layer, but the destroy was never called on the C++ object, creating a crash in the tear-down (in my case when the mamaPublisher tries to destroy its list for a 2^nd time).

I think in OM 2.3 and before the absence of the onDestroy cb prevented this bug from occurring, but it still seems incorrect to destroy the C/mamaPublisher if there is a C++/MamaPublisher holding it. It’s probably reasonable to assume that if an app is destroying its transport that it will not destroy its publishers after that.

When destroying the MamaPublisher before the MamaTransport this does not occur since the mamaPublisher is removed from the transport.

Is the code for a transport to trigger publishers to destroy themselves sufficiently embedded that it could not be removed since existing apps depend on it?

Has anyone else seen this in testing?

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 Market Data Services Engineers | CIB_Market_Data_Services_Engineers@...

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

Apologies – originally sent this out on Monday but I think it may have been rejected from the mailing list due to not updating my subscription with my new Vela email address.

Hi Reed,

I don’t think we’ve seen this one – although perhaps others have, but you’re the first to report it.  I’ll have to take more of a look at this, especially this –

>> Is the code for a transport to trigger publishers to destroy themselves sufficiently embedded that it could not be removed since existing apps depend on it?

I’m currently looking through this to confirm just how necessary this is.  Also, this is a good point –

>> It’s probably reasonable to assume that if an app is destroying its transport that it will not destroy its publishers after that.

The transport should be the last object destroyed anyway, ie all other MAMA objects should be destroyed before it – but previously the fate of publishers probably didn’t matter that much.

Thanks

Stuart

Hi,

Testing with OM 2.4.1.

If a C++/MamaPublisher is not destroyed before the C++/MamaTransport is destroyed, then the C/mamaTransport will notify each C/mamaPublisher that the transport is going away, and the mamaPublisher will call destroy on itself. This triggers the onDestroy callbacks, which vector up to the C++ layer, but the destroy was never called on the C++ object, creating a crash in the tear-down (in my case when the mamaPublisher tries to destroy its list for a 2^nd time).

I think in OM 2.3 and before the absence of the onDestroy cb prevented this bug from occurring, but it still seems incorrect to destroy the C/mamaPublisher if there is a C++/MamaPublisher holding it. It’s probably reasonable to assume that if an app is destroying its transport that it will not destroy its publishers after that.

When destroying the MamaPublisher before the MamaTransport this does not occur since the mamaPublisher is removed from the transport.

Is the code for a transport to trigger publishers to destroy themselves sufficiently embedded that it could not be removed since existing apps depend on it?

Has anyone else seen this in testing?

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 Market Data Services Engineers | CIB_Market_Data_Services_Engineers@...

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

The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC

Hi Reed,

I was looking at this and trying to reproduce exactly what you were seeing but wasn’t able to see a core, which makes me think I might be misunderstanding something.

I was wondering if you had a trivial example/code/pseudocode that shows exactly the steps taken to make this crash?

Thanks

Stuart

Apologies – originally sent this out on Monday but I think it may have been rejected from the mailing list due to not updating my subscription with my new Vela email address.

Hi Reed,

I don’t think we’ve seen this one – although perhaps others have, but you’re the first to report it.  I’ll have to take more of a look at this, especially this –

>> Is the code for a transport to trigger publishers to destroy themselves sufficiently embedded that it could not be removed since existing apps depend on it?

I’m currently looking through this to confirm just how necessary this is.  Also, this is a good point –

>> It’s probably reasonable to assume that if an app is destroying its transport that it will not destroy its publishers after that.

The transport should be the last object destroyed anyway, ie all other MAMA objects should be destroyed before it – but previously the fate of publishers probably didn’t matter that much.

Thanks

Stuart

Hi,

Testing with OM 2.4.1.

If a C++/MamaPublisher is not destroyed before the C++/MamaTransport is destroyed, then the C/mamaTransport will notify each C/mamaPublisher that the transport is going away, and the mamaPublisher will call destroy on itself. This triggers the onDestroy callbacks, which vector up to the C++ layer, but the destroy was never called on the C++ object, creating a crash in the tear-down (in my case when the mamaPublisher tries to destroy its list for a 2^nd time).

I think in OM 2.3 and before the absence of the onDestroy cb prevented this bug from occurring, but it still seems incorrect to destroy the C/mamaPublisher if there is a C++/MamaPublisher holding it. It’s probably reasonable to assume that if an app is destroying its transport that it will not destroy its publishers after that.

When destroying the MamaPublisher before the MamaTransport this does not occur since the mamaPublisher is removed from the transport.

Is the code for a transport to trigger publishers to destroy themselves sufficiently embedded that it could not be removed since existing apps depend on it?

Has anyone else seen this in testing?

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 Market Data Services Engineers | CIB_Market_Data_Services_Engineers@...

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

The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC

The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC

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