OM 2.4.1 and transport destroy also destroys mama_publisher

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



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 2nd 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?






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 for disclosures relating to European legal entities.