Date   

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

jenkins@...
 

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

[fquinn.ni] [PLAT-589] - Mapping STATUS_DELETE in
	mama/jni/src/com/wombat/mama/MamaMsgStatus.java


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

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #88
  • Build Status: Successful
  • Build Warnings: 0
  • 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-589] - Mapping STATUS_DELETE in
	mama/jni/src/com/wombat/mama/MamaMsgStatus.java


Results for OpenMAMA_Next_Branch_VS_2012 CI run with latest changes:

  • CI Project Name: OpenMAMA_Next_Branch_VS_2012
  • Build Number: #73
  • Build Status: Successful
  • Build Warnings: 2949
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

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!

[noreply] CI: Added new script to use for CI builds (#196)
	release_scripts/ci-run.py


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

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #87
  • Build Status: Successful
  • Build Warnings: 0
  • 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!

[noreply] CI: Added new script to use for CI builds (#196)
	release_scripts/ci-run.py


Results for OpenMAMA_Next_Branch_VS_2012 CI run with latest changes:

  • CI Project Name: OpenMAMA_Next_Branch_VS_2012
  • Build Number: #72
  • Build Status: Successful
  • Build Warnings: 2949
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

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


OpenMAMA End of Support for Avis

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

I'd like too propose that we stop maintaining the avis bridge for OpenMAMA and that the release which just went out (2.4.1) is the last to support avis, which may then be removed from the code base.

This has already been agreed by the Steering Committee, but I want to put it out there to the users and dev mailing lists to see if there are any further objections, or if anyone would like to step up and take ownership of the bridge (e.g. split out an external OpenMAMA-avis project).

There are several reasons for wanting to retire support for avis:

1. To the best of my knowledge, nobody is using it (we never hear of it on the mailing list any more).
2. Avis itself hasn't been updated in 7 years
3. It's a resource drain on any new functionality we may add for zero return.
4. Even today, doesn't pass all unit tests because the payload doesn't support all OpenMAMA functionality.

It's all about focus - I want to make sure that we spend time focusing on what people are actively using.

If anyone has any sentimental attachment to the avis bridge, please speak up now.

We are currently scheduling the removal of avis from the codebase on 25th July.

Cheers,
Frank


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

jenkins@...
 

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

[noreply] SCONS: Fixed build issue with multiple build types on windows (#195)
	mama/c_cpp/src/c/fieldcache/fieldcachelist.h
	mama/c_cpp/src/c/mamainternal.h
	mama/c_cpp/src/c/bridge/qpid/SConscript.win
	mama/c_cpp/src/c/fieldcache/fieldcachemap.h
	mamda/dotnet/SConscript.win
	mamda/c_cpp/SConscript.win
	mama/c_cpp/src/c/fieldcache/fieldcachefieldimpl.h
	mama/c_cpp/SConscript.win
	mama/c_cpp/src/gunittest/c/SConscript
	common/c_cpp/src/gunittest/SConscript
	common/c_cpp/SConscript.win
	mama/c_cpp/src/c/bridge/qpid/SConscript
	mama/dotnet/SConscript.win
	mama/c_cpp/src/c/payload/qpidmsg/SConscript.win
	mama/c_cpp/src/gunittest/cpp/SConscript
	site_scons/community/windows.py
	mama/jni/SConscript.win
	mama/c_cpp/src/c/fieldcache/fieldcachemaparray.h
	mama/c_cpp/src/examples/cpp/SConscript.win
	mamda/java/SConscript.win
	mama/c_cpp/src/gunittest/c/MainUnitTestC.h
	mama/c_cpp/src/examples/c/SConscript.win
	mama/c_cpp/src/c/fieldcache/fieldcachevector.h
	common/c_cpp/src/gunittest/c/SConscript
	mama/c_cpp/src/gunittest/c/mamamsg/msgvectortests.cpp
	mama/c_cpp/src/gunittest/SConscript
	mama/c_cpp/src/c/msgutils.h
	site_scons/community/command_line.py
	mama/c_cpp/src/gunittest/c/payload/payloadvectortests.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: #86
  • Build Status: Successful
  • Build Warnings: 0
  • 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!

[noreply] SCONS: Fixed build issue with multiple build types on windows (#195)
	mama/c_cpp/src/gunittest/c/payload/payloadvectortests.cpp
	mama/jni/SConscript.win
	mamda/dotnet/SConscript.win
	mama/c_cpp/src/c/fieldcache/fieldcachemaparray.h
	site_scons/community/windows.py
	common/c_cpp/src/gunittest/c/SConscript
	mama/c_cpp/src/gunittest/c/mamamsg/msgvectortests.cpp
	mama/c_cpp/src/c/msgutils.h
	mamda/java/SConscript.win
	mama/c_cpp/src/gunittest/c/SConscript
	mama/c_cpp/src/c/bridge/qpid/SConscript
	mama/c_cpp/src/c/mamainternal.h
	site_scons/community/command_line.py
	mama/c_cpp/src/gunittest/c/MainUnitTestC.h
	mama/c_cpp/src/c/fieldcache/fieldcachelist.h
	common/c_cpp/SConscript.win
	mama/c_cpp/src/gunittest/cpp/SConscript
	mama/c_cpp/SConscript.win
	mama/c_cpp/src/c/fieldcache/fieldcachefieldimpl.h
	mama/dotnet/SConscript.win
	mama/c_cpp/src/c/fieldcache/fieldcachevector.h
	mamda/c_cpp/SConscript.win
	common/c_cpp/src/gunittest/SConscript
	mama/c_cpp/src/examples/cpp/SConscript.win
	mama/c_cpp/src/gunittest/SConscript
	mama/c_cpp/src/examples/c/SConscript.win
	mama/c_cpp/src/c/payload/qpidmsg/SConscript.win
	mama/c_cpp/src/c/bridge/qpid/SConscript.win
	mama/c_cpp/src/c/fieldcache/fieldcachemap.h


Results for OpenMAMA_Next_Branch_VS_2012 CI run with latest changes:

  • CI Project Name: OpenMAMA_Next_Branch_VS_2012
  • Build Number: #71
  • Build Status: Successful
  • Build Warnings: 2949
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

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!

[Frank Quinn] MAMA: Fixed comment related warning in MamaSubscription.h
	mama/c_cpp/src/cpp/mama/MamaSubscription.h


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

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #85
  • Build Status: Successful
  • Build Warnings: 0
  • 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!

[Frank Quinn] MAMA: Fixed comment related warning in MamaSubscription.h
	mama/c_cpp/src/cpp/mama/MamaSubscription.h


Results for OpenMAMA_Next_Branch_VS_2012 CI run with latest changes:

  • CI Project Name: OpenMAMA_Next_Branch_VS_2012
  • Build Number: #70
  • Build Status: Successful
  • Build Warnings: 2949
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

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


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

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









521 - 540 of 2314