Date   

Re: FW: OM 2.4.1 and transport destroy also destroys mama_publisher

Dmitri Fedorov <dfedorov.solace@...>
 

Hi,

I've looked at Reed's sample he gave to us and, indeed, it crashes with double delete.

In our opinion to accommodate this particular application logic (destroy call on the publisher and deleting of the publisher on the publisher callback) a patch is needed to be applied in the OpenMAMA layer.

We have two different approaches we could suggest to OpenMAMA for this patch.

Our testing tool deletes the publisher class instance right after calling its “destroy” method, like so:

​> mama_log(MAMA_LOG_LEVEL_NORMAL, "delete publisher");
> pub->destroy();
our testing tool add this --> delete pub;


Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On 14 July 2016 at 14:17, Alpert, Reed via Openmama-dev <openmama-dev@...> wrote:

Hi,

 

I uploaded om_241_transport_pub_destroy.cpp into the jpmc incoming ftp dir.

It should crash when ran as-is (may need some hard-coded string changes for your end), and then on line 64 if you turn that code on it will be ok.

 

It’s the delete call in the onDestroy that does it.

 

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

 

 

From: Stuart Beattie [mailto:sbeattie@...]
Sent: Thursday, July 14, 2016 1:51 PM
To: Stuart Beattie; Alpert, Reed; openmama-dev@...
Subject: RE: [Openmama-dev] FW: OM 2.4.1 and transport destroy also destroys mama_publisher

 

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

 

STUART BEATTIE

Senior Software Engineer

 

O. +44 28909 93365

M.

sbeattie@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Stuart Beattie
Sent: 13 July 2016 10:25
To: Alpert, Reed <reed.alpert@...>; openmama-dev@...
Subject: [Openmama-dev] FW: OM 2.4.1 and transport destroy also destroys mama_publisher

 

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

 

STUART BEATTIE

Senior Software Engineer

 

O. +44 28909 93365

M.

sbeattie@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alpert, Reed via Openmama-dev
Sent: 07 July 2016 20:33
To: openmama-dev@...
Subject: [Openmama-dev] OM 2.4.1 and transport destroy also destroys mama_publisher

 

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

 

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.


_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev



Re: FW: OM 2.4.1 and transport destroy also destroys mama_publisher

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

Hi,

 

I uploaded om_241_transport_pub_destroy.cpp into the jpmc incoming ftp dir.

It should crash when ran as-is (may need some hard-coded string changes for your end), and then on line 64 if you turn that code on it will be ok.

 

It’s the delete call in the onDestroy that does it.

 

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

 

 

From: Stuart Beattie [mailto:sbeattie@...]
Sent: Thursday, July 14, 2016 1:51 PM
To: Stuart Beattie; Alpert, Reed; openmama-dev@...
Subject: RE: [Openmama-dev] FW: OM 2.4.1 and transport destroy also destroys mama_publisher

 

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

 

STUART BEATTIE

Senior Software Engineer

 

O. +44 28909 93365

M.

sbeattie@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Stuart Beattie
Sent: 13 July 2016 10:25
To: Alpert, Reed <reed.alpert@...>; openmama-dev@...
Subject: [Openmama-dev] FW: OM 2.4.1 and transport destroy also destroys mama_publisher

 

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

 

STUART BEATTIE

Senior Software Engineer

 

O. +44 28909 93365

M.

sbeattie@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alpert, Reed via Openmama-dev
Sent: 07 July 2016 20:33
To: openmama-dev@...
Subject: [Openmama-dev] OM 2.4.1 and transport destroy also destroys mama_publisher

 

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

 

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.


Re: FW: OM 2.4.1 and transport destroy also destroys mama_publisher

Stuart Beattie
 

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

 

STUART BEATTIE

Senior Software Engineer

 

O. +44 28909 93365

M.

sbeattie@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Stuart Beattie
Sent: 13 July 2016 10:25
To: Alpert, Reed <reed.alpert@...>; openmama-dev@...
Subject: [Openmama-dev] FW: OM 2.4.1 and transport destroy also destroys mama_publisher

 

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

 

STUART BEATTIE

Senior Software Engineer

 

O. +44 28909 93365

M.

sbeattie@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alpert, Reed via Openmama-dev
Sent: 07 July 2016 20:33
To: openmama-dev@...
Subject: [Openmama-dev] OM 2.4.1 and transport destroy also destroys mama_publisher

 

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

 

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


FW: OM 2.4.1 and transport destroy also destroys mama_publisher

Stuart Beattie
 

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

 

STUART BEATTIE

Senior Software Engineer

 

O. +44 28909 93365

M.

sbeattie@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alpert, Reed via Openmama-dev
Sent: 07 July 2016 20:33
To: openmama-dev@...
Subject: [Openmama-dev] OM 2.4.1 and transport destroy also destroys mama_publisher

 

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

 

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


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] SCONS: Updated scons script to build noop on windows (#193)
	mama/c_cpp/src/c/entitlement/SConscript
	mama/c_cpp/SConscript.win
	mama/c_cpp/src/c/entitlement/noop/SConscript


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #84
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


OM 2.4.1 and transport destroy also destroys mama_publisher

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

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

 

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.


Re: tick42blp bridge and openmama 2.4.1

Frank Quinn <fquinn.ni@...>
 

Hi Nestor,

Tick42 folks will be able to shed more light on this but it looks to me like you need a version of the bridge which is built for OpenMAMA 2.4.x - that is when that mandatory bridge function was introduced.

Cheers,
Frank


On Tue, 5 Jul 2016, 17:28 Macrux, <kmacrux@...> wrote:
Hi all,

I am migrating to release 2.4.1 but had some issues related to tick42blp bridge. Next are the message I got when run mamalistenc:

mamalistenc -B -S "BlpMktData" -s "VOD LN Equity" -tport blp_tport -m tick42blp -threads 1 -v -v -v -v


2016-07-05 09:38:15: (20e4) : mamaInternal_setMetaProperty (): Successfully set meta property mama.runtime_version=2.4.1.

2016-07-05 09:38:15: (20e4) : mama_loadBridge (): Failed to initialise middleware bridge [tick42blp]

. Cannot find function tick42blpBridge_init in implementation library.

2016-07-05 09:38:15: (20e4) : Using path specified in WOMBAT_PATH

2016-07-05 09:38:15: (20e4) : Using default properties file mama.properties

2016-07-05 09:38:15: (20e4) : Attempting to load MAMA properties from C:\marketLib\config

Failed to initialize MAMA STATUS: 26 (NO_BRIDGE_IMPL)

I read weeks ago that someone post a related issue between tick42blp and release 2.4 but I'm not sure how was this solved or if they are the same problem.

Thanks in advance for any help you could give me.

Cheers,

-Nestor

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev


tick42blp bridge and openmama 2.4.1

macrux
 

Hi all,

I am migrating to release 2.4.1 but had some issues related to tick42blp bridge. Next are the message I got when run mamalistenc:

mamalistenc -B -S "BlpMktData" -s "VOD LN Equity" -tport blp_tport -m tick42blp -threads 1 -v -v -v -v


2016-07-05 09:38:15: (20e4) : mamaInternal_setMetaProperty (): Successfully set meta property mama.runtime_version=2.4.1.

2016-07-05 09:38:15: (20e4) : mama_loadBridge (): Failed to initialise middleware bridge [tick42blp]

. Cannot find function tick42blpBridge_init in implementation library.

2016-07-05 09:38:15: (20e4) : Using path specified in WOMBAT_PATH

2016-07-05 09:38:15: (20e4) : Using default properties file mama.properties

2016-07-05 09:38:15: (20e4) : Attempting to load MAMA properties from C:\marketLib\config

Failed to initialize MAMA STATUS: 26 (NO_BRIDGE_IMPL)

I read weeks ago that someone post a related issue between tick42blp and release 2.4 but I'm not sure how was this solved or if they are the same problem.

Thanks in advance for any help you could give me.

Cheers,

-Nestor


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[Frank Quinn] COMMON: Fixed leaking and corruption in properties parsing
	common/c_cpp/src/c/property.c

[Frank Quinn] QPID: Fixed small leak on shutdown in libevent
	mama/c_cpp/src/c/bridge/qpid/io.c

[Frank Quinn] COMMON: Fixed memory leak on shutdown for memorypool
	common/c_cpp/src/c/mempool.c

[Frank Quinn] UNITTEST: Removed several leaks across several unit tests
	mama/c_cpp/src/gunittest/c/publishertest.cpp
	mama/c_cpp/src/gunittest/c/subscriptiontest.cpp
	mama/c_cpp/src/gunittest/c/fieldcache/fieldcacheiteratortest.cpp
	mama/c_cpp/src/gunittest/c/fieldcache/fieldcachetest.cpp
	mama/c_cpp/src/gunittest/c/iotest.cpp
	mama/c_cpp/src/gunittest/cpp/MamaPublisherTest.cpp

[Frank Quinn] MAMA: Removed shutdown leak when running mama in background
	mama/c_cpp/src/c/mama.c
	mama/c_cpp/src/c/bridge.h

[Frank Quinn] MAMA: Fixed memory leak in entitlement subscriptions
	mama/c_cpp/src/c/subscription.c
	mama/c_cpp/src/c/entitlement.c

[Frank Quinn] MAMA: Simplified MAMA properties parsing in MAMA
	mama/c_cpp/src/c/mama.c

[Frank Quinn] MAMA: Simplified the timezone thread
	mama/c_cpp/src/c/mama.c
	mama/c_cpp/src/c/timezone.c
	mama/c_cpp/src/c/mama/timezone.h

[Frank Quinn] MAMA: Fixed leak in publisher callbacks and MAMA C++ Queue
	mama/c_cpp/src/cpp/MamaPublisher.cpp
	mama/c_cpp/src/cpp/mamacpp.cpp
	mama/c_cpp/src/c/publisher.c

[Frank Quinn] UNITTEST: Fixed several leaks and bugs in unit test
	mama/c_cpp/src/gunittest/c/middleware/middlewareInboxTests.cpp
	mama/c_cpp/src/gunittest/c/middleware/middlewareIoTests.cpp
	mama/c_cpp/src/gunittest/c/middleware/middlewareSubscriptionTests.cpp
	mama/c_cpp/src/gunittest/cpp/MamaPublisherTest.cpp
	mama/c_cpp/src/gunittest/c/middleware/middlewareTransportTests.cpp
	mama/c_cpp/src/gunittest/cpp/MamaTimerTest.cpp
	mama/c_cpp/src/gunittest/c/middleware/middlewareMsgTests.cpp
	mama/c_cpp/src/gunittest/c/middleware/middlewareQueueTests.cpp
	mama/c_cpp/src/gunittest/c/middleware/middlewareTimerTests.cpp

[Frank Quinn] MAMACPP: Added C++ default queue wrapper vector clearing
	mama/c_cpp/src/cpp/mamacpp.cpp
	mama/c_cpp/src/c/bridge/qpid/bridge.c

[Frank Quinn] UNITTEST: Added memory leak fixes for DateTime unit tests
	mama/c_cpp/src/gunittest/c/mamadatetime/datetimerangetest.cpp
	mama/c_cpp/src/gunittest/c/mamadatetime/datetimetest.cpp

[Frank Quinn] MAMA: Fixed memory leak when getting a date time from MamaMsg
	mama/c_cpp/src/c/msg.c

[Frank Quinn] QPID: Refactored vector messages in qpid to use field functionality
	mama/c_cpp/src/c/payload/qpidmsg/payload.c

[Frank Quinn] UNITTEST: Fixed several unit test leaks in MAMA Messages
	mama/c_cpp/src/gunittest/c/mamamsg/msgfieldvectortests.cpp
	mama/c_cpp/src/gunittest/c/mamamsg/msgiterationtests.cpp
	mama/c_cpp/src/gunittest/c/mamamsg/msgfieldatomictests.cpp
	mama/c_cpp/src/gunittest/c/mamamsg/msgfieldcompositetests.cpp
	mama/c_cpp/src/gunittest/c/mamamsg/msgcompositetests.cpp
	mama/c_cpp/src/gunittest/c/mamamsg/msggeneraltests.cpp

[Frank Quinn] UNITTEST: Another round of memory leak and bug fixes
	mama/c_cpp/src/gunittest/c/payload/payloadgeneraltests.cpp
	mama/c_cpp/src/gunittest/c/payload/fieldcompositetests.cpp
	mama/c_cpp/src/gunittest/c/payload/payloadcompositetests.cpp
	mama/c_cpp/src/gunittest/c/payload/fieldvectortests.cpp

[Frank Quinn] UNITTEST: Fixed another round of memory leaks inside the tests
	mama/c_cpp/src/gunittest/c/payload/fieldcompositetests.cpp
	mama/c_cpp/src/gunittest/c/payload/fieldatomictests.cpp
	mama/c_cpp/src/gunittest/c/payload/payloadgeneraltests.cpp
	mama/c_cpp/src/gunittest/c/payload/payloadcompositetests.cpp

[Frank Quinn] UNITTEST: Fixed thread leak in MAMA Date Time unit tests
	mama/c_cpp/src/gunittest/cpp/MamaDateTimeTest.cpp

[Frank Quinn] UNITTEST: Fixed leak in middleware general unit test
	mama/c_cpp/src/gunittest/c/middleware/middlewareGeneralTests.cpp

[Frank Quinn] UNITTEST: Fixed leak in payload unit tests
	mama/c_cpp/src/gunittest/c/payload/payloadgeneraltests.cpp

[Frank Quinn] UNITTEST: Fixed several leaks in MamaMsg unit tests
	mama/c_cpp/src/gunittest/c/mamamsg/msgfieldcompositetests.cpp
	mama/c_cpp/src/gunittest/c/mamamsg/msggeneraltests.cpp

[Frank Quinn] QPID: Modified setByteBuffer to copy rather than reference
	mama/c_cpp/src/c/payload/qpidmsg/payload.c

[Frank Quinn] QPID: Undoing recent pn_message change
	mama/c_cpp/src/c/payload/qpidmsg/payload.c

[Frank Quinn] UNITTEST: Added several bugs in MAMA Message unit tests
	mama/c_cpp/src/gunittest/c/payload/payloadgeneraltests.cpp
	mama/c_cpp/src/gunittest/c/mamamsg/msgcompositetests.cpp
	mama/c_cpp/src/gunittest/c/mamamsg/msggeneraltests.cpp

[Frank Quinn] MAMAMSG: Fixed leak in detach and mamaMsg_getMsg
	mama/c_cpp/src/c/payload/qpidmsg/qpidcommon.h
	mama/c_cpp/src/c/payload/qpidmsg/payload.c
	mama/c_cpp/src/c/msg.c

[Frank Quinn] QPID: Fixed memory ownership of pn_message for setting message buffer
	mama/c_cpp/src/c/payload/qpidmsg/payload.c
	mama/c_cpp/src/gunittest/c/payload/payloadgeneraltests.cpp


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #83
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] PLAT-438: Implementing a seperate timeout for subscription recaps in
	mama/c_cpp/src/c/dqstrategy.c
	mama/c_cpp/src/c/subscriptionimpl.h
	mamda/c_cpp/src/cpp/MamdaSubscription.cpp
	mama/c_cpp/src/c/mama/subscription.h
	mama/c_cpp/src/c/subscription.c
	mama/c_cpp/src/cpp/mama/MamaSubscription.h
	mamda/c_cpp/src/cpp/mamda/MamdaSubscription.h
	mama/c_cpp/src/cpp/MamaSubscription.cpp


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #82
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Openmama 2.4.0 over windows no bridge noop

Dmitri Fedorov <dfedorov.solace@...>
 

In case someone runs into the same issue

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

---------- Forwarded message ----------
From: Macrux <kmacrux@...>
Date: 29 June 2016 at 17:00
Subject: Re: [Openmama-dev] Openmama 2.4.0 over windows no bridge noop
To: Dmitri Fedorov <dfedorov.solace@...>


Hi Dmitri, it worked perfect. Thank you very much :)

On 29 June 2016 at 15:13, Dmitri Fedorov <dfedorov.solace@...> wrote:
Hi Nestor


Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On 29 June 2016 at 15:22, Macrux <kmacrux@...> wrote:
Hi Dmitri,

Actually I'm running out of time because I need to test some work related the new broker transport. I would really apreciate if you can share the binaries with me. In the other hand, I could download the  2.4.1 release as well (in fact I already did it and it is also missing the libmamaentnoop.dll) but how could I defer the entitlements, I mean, is there any property for that or something else?

Thanks in advance,

-Nestor

On 29 June 2016 at 13:56, Dmitri Fedorov <dfedorov.solace@...> wrote:
​Nestor,

It should be able run without it if entitlements are deferred, but 2.4.0 doesn't handle them (deferred entitlements) well, 2.4.1 does.

I'd suggest to wait for Vela (ex SR LAbs) folks input on this (packaging) issue, I personally compile it with DevStudio​ 2015 and can share it with you over GitHub if you're out of other options.


Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On 29 June 2016 at 14:41, Macrux <kmacrux@...> wrote:
Hi Dmitri,

No, I don't have it, It doesn't come in the windows release package, I think.

-Nestor

On 29 June 2016 at 13:35, Dmitri Fedorov <dfedorov.solace@...> wrote:
Sorry, I meant libmamaentnoop.dll :-)

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On 29 June 2016 at 14:34, Dmitri Fedorov <dfedorov.solace@...> wrote:
​Hi Nestor,

Do you have libmamaentnoop.so in your OpenMAMA lib directory?


Cheers​

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On 29 June 2016 at 14:26, Macrux <kmacrux@...> wrote:
Hi All,

I'm trying to run OpenMAMA 2.4.0 x86 on windows 8. The package was downloaded from Github releases page. I'm getting this message:

\bin\dynamic>mamapublisherc.exe -tport pub -m qpid
Starting Publisher with:
  topic:              MAMA_TOPIC
  inbound topic:      MAMA_INBOUND_TOPIC
  interval            0.500000
  transport:          pub
2016-06-29 12:31:45: mama_loadPayloadBridge(): Could not open entitlement bridge
library [noop] [126]
2016-06-29 12:31:45: mama_openWithProperties(): Could not load noop entitlements
library.
Error initializing mama: NO_BRIDGE_IMPL


Currently I have an OpenMAMA 2.3.1 running on the same machine and everything goes well, so the problem should be with this specific release and that noop library. Could anyone help me?

Thanks in advance,

-Nestor.

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev










Re: Openmama 2.4.0 over windows no bridge noop

Dmitri Fedorov <dfedorov.solace@...>
 

Sorry, I meant libmamaentnoop.dll :-)

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On 29 June 2016 at 14:34, Dmitri Fedorov <dfedorov.solace@...> wrote:
​Hi Nestor,

Do you have libmamaentnoop.so in your OpenMAMA lib directory?


Cheers​

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On 29 June 2016 at 14:26, Macrux <kmacrux@...> wrote:
Hi All,

I'm trying to run OpenMAMA 2.4.0 x86 on windows 8. The package was downloaded from Github releases page. I'm getting this message:

\bin\dynamic>mamapublisherc.exe -tport pub -m qpid
Starting Publisher with:
  topic:              MAMA_TOPIC
  inbound topic:      MAMA_INBOUND_TOPIC
  interval            0.500000
  transport:          pub
2016-06-29 12:31:45: mama_loadPayloadBridge(): Could not open entitlement bridge
library [noop] [126]
2016-06-29 12:31:45: mama_openWithProperties(): Could not load noop entitlements
library.
Error initializing mama: NO_BRIDGE_IMPL


Currently I have an OpenMAMA 2.3.1 running on the same machine and everything goes well, so the problem should be with this specific release and that noop library. Could anyone help me?

Thanks in advance,

-Nestor.

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev




Re: Openmama 2.4.0 over windows no bridge noop

Dmitri Fedorov <dfedorov.solace@...>
 

​Hi Nestor,

Do you have libmamaentnoop.so in your OpenMAMA lib directory?


Cheers​

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On 29 June 2016 at 14:26, Macrux <kmacrux@...> wrote:
Hi All,

I'm trying to run OpenMAMA 2.4.0 x86 on windows 8. The package was downloaded from Github releases page. I'm getting this message:

\bin\dynamic>mamapublisherc.exe -tport pub -m qpid
Starting Publisher with:
  topic:              MAMA_TOPIC
  inbound topic:      MAMA_INBOUND_TOPIC
  interval            0.500000
  transport:          pub
2016-06-29 12:31:45: mama_loadPayloadBridge(): Could not open entitlement bridge
library [noop] [126]
2016-06-29 12:31:45: mama_openWithProperties(): Could not load noop entitlements
library.
Error initializing mama: NO_BRIDGE_IMPL


Currently I have an OpenMAMA 2.3.1 running on the same machine and everything goes well, so the problem should be with this specific release and that noop library. Could anyone help me?

Thanks in advance,

-Nestor.

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev



Openmama 2.4.0 over windows no bridge noop

macrux
 

Hi All,

I'm trying to run OpenMAMA 2.4.0 x86 on windows 8. The package was downloaded from Github releases page. I'm getting this message:

\bin\dynamic>mamapublisherc.exe -tport pub -m qpid
Starting Publisher with:
  topic:              MAMA_TOPIC
  inbound topic:      MAMA_INBOUND_TOPIC
  interval            0.500000
  transport:          pub
2016-06-29 12:31:45: mama_loadPayloadBridge(): Could not open entitlement bridge
library [noop] [126]
2016-06-29 12:31:45: mama_openWithProperties(): Could not load noop entitlements
library.
Error initializing mama: NO_BRIDGE_IMPL


Currently I have an OpenMAMA 2.3.1 running on the same machine and everything goes well, so the problem should be with this specific release and that noop library. Could anyone help me?

Thanks in advance,

-Nestor.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] PLAT-318: No BOOK RECAP during FT takeover when dqstrategy=ignoredups
	mama/c_cpp/src/c/dqstrategy.c


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #81
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[dfedorov.solace] Wildcard subscription OnMsg callback is called with NULL instead of
	mama/c_cpp/src/c/subscription.c


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #80
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Re: subscription is using destroyed publisher

Frank Quinn <f.quinn@...>
 

Hi Dmitri,

 

Did you folks get everything that you needed from Gitter around this one or is this a different issue?

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: Friday, June 10, 2016 7:30 PM
To: openmama-dev <openmama-dev@...>
Subject: [Openmama-dev] subscription is using destroyed publisher

 

Hello gents, could you please confirm that the following looks like a MAMA layer issue, or maybe our bridge is not acting properly?

The issue: there is a subscription in process of activation or deactivation on one thread, and in that process it is trying to use a publisher that is in process of being destroyed or was already destoroyed in a different threat.

We would expect this publisher not being used (as it clearly has a state different from LIVE).

What do you think?

Thank you

 

Regards,

Dmitri Fedorov

Software Architect

Solace Systems, Inc.

Ottawa, ON Canada

 

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.


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. SR Labs LLC


Re: Gitter vs IRC

Frank Quinn <f.quinn@...>
 

Hi Folks,

 

All links on the openmama website have now been updated to point to Gitter rather than IRC (and a few pages have been cleaned up during the review). If anyone spots any stale references to IRC, please let me know.

 

I am pleased to say it really has grown to be quite lively - we already have more active participants than we ever had on IRC so I think it was the right move.

 

We also just updated wiki.openmama.org to point to the github wiki rather than the old mediawiki installation to avoid duplication and forking of our development documentation.

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Frank Quinn
Sent: Monday, June 13, 2016 9:26 AM
To: openmama-dev <openmama-dev@...>; openmama-users@...
Subject: Re: [Openmama-dev] Gitter vs IRC

 

Hi folks,

As we have heard no objections, we'll be going ahead with the move to gitter. It is ready to go right now and you'll find the usual IRC folks in Gitter. Meanwhile we'll work on updating all documentation etc to point to gitter rather than freenode.

Cheers,

Frank

 

On Tue, May 31, 2016 at 9:05 PM, Frank Quinn <fquinn.ni@...> wrote:

Hi folks,

We're currently looking at gitter as a potential IRC compatible replacement and my personal opinion is that we should go with it.

 

You can already mess about in the proposed channel; you can read anonymously, or use a github or twitter account to contribute: 

 

https://gitter.im/OpenMAMA/OpenMAMA

It has several great features:

1. Instant messages are persisted to the room, so you will see history when you log in
2. Sensible concurrent login access with no username1 nonsense
3. Web front end comes for free
4. Provided by github so integrates very nicely into the project wiki etc
5. Native client provided for Mac, windows, Linux, iPhone and android
6. Also compatible with standard IRC clients

Downsides:

1. It increases the github lock-in
2. You'll need a github or twitter account to contribute

If anyone has any feedback about making the move, please speak up now. I'm sending this to both users and developers because it will impact both and I'll welcome and consider all responses. I'd hope that we can agree a decision one way or another by 7th June, then (if necessary) take the plunge.

Cheers,
Frank

 


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. SR Labs LLC


Re: OpenMAMA-2.4.1 (hotfix release for deferred entitlements)

Frank Quinn <f.quinn@...>
 

Hi Folks,


I can confirm that 2.4.1 is now available – see:

 

https://github.com/OpenMAMA/OpenMAMA/releases

 

Cheers,

Frank

 

From: Frank Quinn
Sent: Monday, June 13, 2016 1:23 PM
To: openmama-dev <openmama-dev@...>; 'openmama-users@...' <openmama-users@...>
Subject: OpenMAMA-2.4.1 (hotfix release for deferred entitlements)

 

Hi Folks,

 

We will be cutting a release shortly which is a hot fix release to include following change:

 

https://github.com/OpenMAMA/OpenMAMA/commit/daf1478b6ecc25b0dd453a56a826bc9b95dc7b18

 

Note that if you have fallen victim to this issue, you will not be able to subscribe to anything, so if you can subscribe to data sources and receive data today, you don’t need to upgrade.

 

Only users of middleware bridges which use deferred entitlements will require this change (i.e. Qpid, Avis, ZeroMQ and SR Labs bridges are unaffected).

 

I am aiming to get binaries available within the next day or two. Alternatively if you build your own, you can go ahead and build off the OpenMAMA-2.4.1 release branch.

 

Cheers,

Frank


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. SR Labs LLC


Code change just landed on origin/master (Successful)

jenkins@...
 

Some changes have just been added to the origin/master branch!

[Matt Mulhern] CLANG Compilation issues
	mama/c_cpp/src/c/mamainternal.h
	mama/c_cpp/src/c/mama/entitlement.h

[Matt Mulhern] SCONS: Darwin build flag changed
	site_scons/community/darwin.py

[Matt Mulhern] MAMAC: Windows build scons fix for entitlements.
	mama/c_cpp/src/c/SConscript.win

[Matt Mulhern] Issue #151 - Adding call to mama_shutdownPlugins() in mama_close
	mama/c_cpp/src/c/mama.c

[Matt Mulhern] Adding CONTRIBUTING.md ISSUE_TEMPLATE.md and PULL_REQUEST_TEMPLATE.md
	.github/ISSUE_TEMPLATE.md
	.github/CONTRIBUTING.md
	.github/PULL_REQUEST_TEMPLATE.md

[Matt Mulhern] Issue #147: removing arg config and old README files.
	.arcconfig
	README

[Frank Quinn] TESTTOOLS: Capture replay bug fix for playbacks with multiple
	mama/c_cpp/src/testtools/capturereplay/c/capturereplayc.c

[Matt Mulhern] ENTITLEMENTS: General tidy up of entitlements checking from issues
	mama/c_cpp/src/c/subscription.c
	mama/c_cpp/src/c/listenermsgcallback.c

[Matt Mulhern] Moving declaration to top of scope for wiindows build compatability.
	mama/c_cpp/src/c/listenermsgcallback.c

[Matt Mulhern] ---------------------------------------------------------- COMMONC:
	common/c_cpp/src/c/windows/port.c

[Frank Quinn] RPM: Fixed rpm script to support new README file name
	release_scripts/openmama.spec
	release_scripts/openmama-rpm.sh

[Matt Mulhern] CAPTUREREPLAY: Gracefully shutting down if unable to create transport.
	mama/c_cpp/src/testtools/capturereplay/c/capturereplayc.c

[Frank Quinn] ENT: Fixed bug with OEA bridge and market data sub
	mama/c_cpp/src/c/mama.c
	mama/c_cpp/src/c/entitlement/noop/noop.h
	mama/c_cpp/src/c/entitlement/oea/oea.c
	mama/c_cpp/src/c/subscription.c
	mama/c_cpp/src/c/entitlement/oea/oea.h
	mama/c_cpp/src/c/mamainternal.h
	mama/c_cpp/src/c/entitlement/noop/noop.c

[Frank Quinn] MAMACPP: Prevention of double destroy callback in CPP application
	mama/c_cpp/src/cpp/MamaSubscription.cpp

[Frank Quinn] QPID: Added implementation for publisher callbacks in qpid bridge
	mama/c_cpp/src/gunittest/c/publishertest.cpp
	mama/c_cpp/src/c/bridge/qpid/qpidbridgefunctions.h
	mama/c_cpp/src/gunittest/cpp/MamaPublisherTest.cpp
	mama/c_cpp/src/c/bridge/qpid/publisher.c

[Frank Quinn] UNITTEST: Fixed valgrind issues with publisher unit tests
	mama/c_cpp/src/c/bridge/qpid/publisher.c
	mama/c_cpp/src/gunittest/cpp/MamaPublisherTest.cpp

[Frank Quinn] QPID: Fixed crash on NULL parameter passed to destroy
	mama/c_cpp/src/c/bridge/qpid/publisher.c

[Matt Mulhern] QPID: Correction order of deletion in
	mama/c_cpp/src/c/bridge/qpid/publisher.c

[Frank Quinn] MAMA: Delete subsctype.c
	mama/c_cpp/src/c/subsctype.c

[Frank Quinn] Solace fix for deferred entitlements MAMA_STATUS_NO_BRIDGE_IMPL error
	mama/c_cpp/src/c/subscription.c

[Frank Quinn] VERSION: Updating version files to 2.4.1
	mama/VERSION.scons
	mama/c_cpp/configure.ac
	mama/jni/build.xml
	mama/c_cpp/src/c/generateMamaSourceFiles.bat
	mamda/VERSION.scons
	mamda/c_cpp/configure.ac
	mamda/c_cpp/src/cpp/generateMamdaVersion.bat
	mamda/java/build.xml


Results for OpenMAMA Master Branch (Qpid Proton) CI run with latest changes:

  • CI Project Name: OpenMAMA Master Branch (Qpid Proton)
  • Build Number: #13
  • Build Status: Successful
  • Total Amount of Tests: 1766
  • Passed: 1766
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.

521 - 540 of 2305