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

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


[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


[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


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


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


[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


[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


[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

Code change(s) just landed on origin/next (Successful) jenkins@... #1791 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.
More
OpenMAMA End of Support for Avis Frank Quinn <fquinn.ni@...> #1790 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
More All Messages By This Member
Code change(s) just landed on origin/next (Successful) jenkins@... #1789 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.
More
Code change(s) just landed on origin/next (Successful) jenkins@... #1788 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.
More
Code change(s) just landed on origin/next (Successful) jenkins@... #1787 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.
More
Code change(s) just landed on origin/next (Successful) jenkins@... #1786 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.
More
Re: FW: OM 2.4.1 and transport destroy also destroys mama_publisher Dmitri Fedorov <dfedorov.solace@...> #1785 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; I've uploaded the code at https://github.com/dfedorov-solace/OpenMAMA-pubsub/blob/master/mamapublishercpp.cpp 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. toggle quoted messageShow quoted text 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 2^nd time). I think in OM 2.3 and before the absence of the onDestroy cb prevented this bug from occurring, but it still seems incorrect to destroy the C/mamaPublisher if there is a C++/MamaPublisher holding it. It’s probably reasonable to assume that if an app is destroying its transport that it will not destroy its publishers after that. When destroying the MamaPublisher before the MamaTransport this does not occur since the mamaPublisher is removed from the transport. Is the code for a transport to trigger publishers to destroy themselves sufficiently embedded that it could not be removed since existing apps depend on it? Has anyone else seen this in testing? Thanks, Reed. Reed Alpert \| Corporate & Investment Bank \| Market Data Services \| J.P. Morgan \| 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 \| T: 718.242.5198 \| M: 917.414.4613 \| reed.alpert@... Alternate Contact: CIB Market Data Services Engineers \| CIB_Market_Data_Services_Engineers@... This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. _______________________________________________ Openmama-dev mailing list Openmama-dev@... https://lists.openmama.org/mailman/listinfo/openmama-dev
More All Messages By This Member
Re: FW: OM 2.4.1 and transport destroy also destroys mama_publisher Alpert, Reed <reed.alpert@...> #1784 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@... toggle quoted messageShow quoted text 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 2^nd time). I think in OM 2.3 and before the absence of the onDestroy cb prevented this bug from occurring, but it still seems incorrect to destroy the C/mamaPublisher if there is a C++/MamaPublisher holding it. It’s probably reasonable to assume that if an app is destroying its transport that it will not destroy its publishers after that. When destroying the MamaPublisher before the MamaTransport this does not occur since the mamaPublisher is removed from the transport. Is the code for a transport to trigger publishers to destroy themselves sufficiently embedded that it could not be removed since existing apps depend on it? Has anyone else seen this in testing? Thanks, Reed. Reed Alpert \| Corporate & Investment Bank \| Market Data Services \| J.P. Morgan \| 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 \| T: 718.242.5198 \| M: 917.414.4613 \| reed.alpert@... Alternate Contact: CIB Market Data Services Engineers \| CIB_Market_Data_Services_Engineers@... This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.
More All Messages By This Member
Re: FW: OM 2.4.1 and transport destroy also destroys mama_publisher Stuart Beattie #1783 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 toggle quoted messageShow quoted text 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 2^nd time). I think in OM 2.3 and before the absence of the onDestroy cb prevented this bug from occurring, but it still seems incorrect to destroy the C/mamaPublisher if there is a C++/MamaPublisher holding it. It’s probably reasonable to assume that if an app is destroying its transport that it will not destroy its publishers after that. When destroying the MamaPublisher before the MamaTransport this does not occur since the mamaPublisher is removed from the transport. Is the code for a transport to trigger publishers to destroy themselves sufficiently embedded that it could not be removed since existing apps depend on it? Has anyone else seen this in testing? Thanks, Reed. Reed Alpert \| Corporate & Investment Bank \| Market Data Services \| J.P. Morgan \| 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 \| T: 718.242.5198 \| M: 917.414.4613 \| reed.alpert@... Alternate Contact: CIB Market Data Services Engineers \| CIB_Market_Data_Services_Engineers@... This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC
More All Messages By This Member
FW: OM 2.4.1 and transport destroy also destroys mama_publisher Stuart Beattie #1782 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 toggle quoted messageShow quoted text 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 2^nd time). I think in OM 2.3 and before the absence of the onDestroy cb prevented this bug from occurring, but it still seems incorrect to destroy the C/mamaPublisher if there is a C++/MamaPublisher holding it. It’s probably reasonable to assume that if an app is destroying its transport that it will not destroy its publishers after that. When destroying the MamaPublisher before the MamaTransport this does not occur since the mamaPublisher is removed from the transport. Is the code for a transport to trigger publishers to destroy themselves sufficiently embedded that it could not be removed since existing apps depend on it? Has anyone else seen this in testing? Thanks, Reed. Reed Alpert \| Corporate & Investment Bank \| Market Data Services \| J.P. Morgan \| 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 \| T: 718.242.5198 \| M: 917.414.4613 \| reed.alpert@... Alternate Contact: CIB Market Data Services Engineers \| CIB_Market_Data_Services_Engineers@... This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC
More All Messages By This Member
Code change(s) just landed on origin/next (Successful) jenkins@... #1781 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.
More
OM 2.4.1 and transport destroy also destroys mama_publisher Alpert, Reed <reed.alpert@...> #1780 Hi, Testing with OM 2.4.1. If a C++/MamaPublisher is not destroyed before the C++/MamaTransport is destroyed, then the C/mamaTransport will notify each C/mamaPublisher that the transport is going away, and the mamaPublisher will call destroy on itself. This triggers the onDestroy callbacks, which vector up to the C++ layer, but the destroy was never called on the C++ object, creating a crash in the tear-down (in my case when the mamaPublisher tries to destroy its list for a 2^nd time). I think in OM 2.3 and before the absence of the onDestroy cb prevented this bug from occurring, but it still seems incorrect to destroy the C/mamaPublisher if there is a C++/MamaPublisher holding it. It’s probably reasonable to assume that if an app is destroying its transport that it will not destroy its publishers after that. When destroying the MamaPublisher before the MamaTransport this does not occur since the mamaPublisher is removed from the transport. Is the code for a transport to trigger publishers to destroy themselves sufficiently embedded that it could not be removed since existing apps depend on it? Has anyone else seen this in testing? Thanks, Reed. Reed Alpert \| Corporate & Investment Bank \| Market Data Services \| J.P. Morgan \| 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 \| T: 718.242.5198 \| M: 917.414.4613 \| reed.alpert@... Alternate Contact: CIB Market Data Services Engineers \| CIB_Market_Data_Services_Engineers@... This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.
More All Messages By This Member
Re: tick42blp bridge and openmama 2.4.1 Frank Quinn <fquinn.ni@...> #1779 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 toggle quoted messageShow quoted text 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
More All Messages By This Member
tick42blp bridge and openmama 2.4.1 macrux #1778 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
More All Messages By This Member
Code change(s) just landed on origin/next (Successful) jenkins@... #1777 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.
More
Code change(s) just landed on origin/next (Successful) jenkins@... #1776 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.
More
Openmama 2.4.0 over windows no bridge noop Dmitri Fedorov <dfedorov.solace@...> #1775 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 :) toggle quoted messageShow quoted text On 29 June 2016 at 15:13, Dmitri Fedorov <dfedorov.solace@...> wrote: Hi Nestor See https://github.com/dfedorov-solace/win32, I hope it helps. 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
More All Messages By This Member
Re: Openmama 2.4.0 over windows no bridge noop Dmitri Fedorov <dfedorov.solace@...> #1774 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. toggle quoted messageShow quoted text 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
More All Messages By This Member
Re: Openmama 2.4.0 over windows no bridge noop Dmitri Fedorov <dfedorov.solace@...> #1773 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. toggle quoted messageShow quoted text 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
More All Messages By This Member
Openmama 2.4.0 over windows no bridge noop macrux #1772 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.
More All Messages By This Member