Date   

Re: Openmama Documentation for subscription onDestroy

Dmitri Fedorov <dfedorov.solace@...>
 

Gents, are you taking this path for 2.4?

Thank you
Dmitri Fedorov


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 Mon, Feb 1, 2016 at 3:18 PM, Christopher Morgan <Christopher.Morgan@...> wrote:

I’ve raised an issue to cover this on github.

 

Here is a link to the issue:

https://github.com/OpenMAMA/OpenMAMA/issues/114

 

Chris Morgan

 

 

From: Alpert, Reed [mailto:reed.alpert@...]
Sent: February-01-16 10:48 AM
To: Duane Pauls <Duane.Pauls@...>; Christopher Morgan <Christopher.Morgan@...>; openmama-dev@...
Subject: RE: Openmama Documentation for subscription onDestroy

 

I think the app needs to call sub->destroy(), then wait for the onDestroy(), and then ‘delete sub’.

 

onDestroy() is a completion event – once you get it you won’t hear from that subscription again (no callbacks of any kind).

 

In order for an app to call C++ or Java ‘delete sub’ w/o sub->destroy the destructor needs to completely disconnect the app from the impl (which as Duane & Chris point out it does not).

In that case the inline onDestroy() does have value in that the app knows it can safely destroy any of its data structures.

 

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 PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Duane Pauls
Sent: Thursday, January 28, 2016 1:39 PM
To: Christopher Morgan; openmama-dev@...
Subject: Re: [Openmama-dev] Openmama Documentation for subscription onDestroy

 

I’ll add a bit of clarification to the problem with the CPP interface if the middleware bridge queues an event to call the onDestroy callback.

 

When an application destructs a MamaSubscription object, the application onDestroy is called inline, and the MamaSubscription object is freed, but the corresponding MamaSubscriptionImpl object is not freed.  So far so good – it is the MamaSubscriptionImpl object pointer that is the closure to the C-layer and this is still valid, unfreed memory.  However, at this point the MamaSubscriptionImpl object’s mCallback pointer still points to the application’s MamaSubscriptionCallback object.  The application may have freed this memory since MamaSubscriptionCallback::onDestroy() has been called.

 

If we look at MamdaSubscription as an example, it in fact does not implement MamaSubscriptionCallback::onDestroy at all.  It will always destroy the callback (MamdaSubscription::mImpl) immediately after destroying the underlying MamaSubscription.  This happens to occur after onDestroy is called since it is called inline with MamaSubscription::~MamaSubscription.  But nevertheless, it is freed immediately after onDestroy is called inline with the call to MamaSubscription::~MamaSubscription().

 

Now, sometime later, the C-layer onDestroy is called.  This calls the static MamaSubscription::onSubscriptionDestroy which calls MamaSubscriptionImpl::InvokeDestroy().  This checks if MamaSubscriptionImpl::mCallback is NULL (it is not – in the case of a MamdaSubscription it is still pointing to a freed MamdaSubscriptionImpl object) and tries to invoke the onDestroy() method.  If the vtable pointer is no longer valid, a core here is quite likely.

 

Even if a core does not occur, the application would see onDestroy() twice – once inline with when the destroy was started and a second time when the lower layer destroy was completed.  It seems the design intent here is to decouple the MamaSubscriptionImpl from everything above it when the MamaSubscription is destroyed.  To do this, it seems the right thing to do in the C++ layer would be to set MamaSubscriptionImpl::mCallback to NULL when setting MamaSubscriptionImpl::mFreed to true (or alternatively include mFreed in the tests that check mCallback == NULL).

 

Should a bug be raised for this issue?  Or should a middleware bridge in fact NOT enqueue the onDestroy callback as stated in the OpenMAMA Bridge Documentation Wiki and instead invoke onDestroy inline?  If the intent is to always invoke the callback inline, it seems the benefit of having a callback in the first place is diminished.

 

Cheers,

Duane

 

From: Christopher Morgan
Sent: Thursday, January 28, 2016 10:30 AM
To:
openmama-dev@...
Subject: Openmama Documentation for subscription onDestroy

 

Hi,

 

I’m with solace dev for the openmama middle bridge and I have question about mamaSubscription onDestroy with the CPP openmama. On the openmama Developer Wiki under Bridge Documentation for myMiddlewareBridgeMamaSubscription_destroy () it states “…the destroy method adds an event to the queue to invokes the destroy callback, which notifies the client application of the successful destroy of the subscription.” Our Bridge currently does this but in the CPP API for openmama the MamaSubscription seems to do an inline onDestroy as a part of the destructor. This does not work well with the enqueuerd onDestroy callback (potential for causing segmentation faults). I’ve also compared to the Qpid bridge which seems to do an inline onDestroy callback as a part their MiddlewareBridgeMamaSubscription_destroy(). Should the onDestroy callback be inline the MiddlewareBridgeMamaSubscription_destroy() like the Qpid to work with the CPP API? Or Is there a problem with the CPP API?

 

Chris Morgan

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



OpenMAMA-2.4.0-rc2 Now Available

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

The second release candidate for OpenMAMA 2.4.0 has just been cut and contains a few fixes put in since RC1 - see https://github.com/OpenMAMA/OpenMAMA/releases for details.

Once again, we appreciate the continued assistance from the community. Assuming no major issues are found, we'll look to pin down a hard date for the 2.4.0 release towards the end of next week.

Cheers,
Frank


Re: can't compile 2.4.0 branch

Damian Maguire <damian.j.maguire@...>
 

Sorry Dmitri, that's what happens when I try and answer emails at 6 in the morning. ;-)

D.


On Thu, 3 Mar 2016 at 15:10, Dmitri Fedorov <dfedorov.solace@...> wrote:
Thank you, yes, "libevent-devel" was missing.

Damian, who is "Dimitry" :-)?

Regards,
Dmitri Fedorov
Software Architect
​grep -i wiki ​
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 Thu, Mar 3, 2016 at 4:45 AM, Frank Quinn <fquinn.ni@...> wrote:

Yeah you can find details on https://github.com/OpenMAMA/OpenMAMA/wiki/Building-on-Linux, but you’re missing libevent-devel.

 

Cheers,

Frank


On Thu, 3 Mar 2016 06:07 Damian Maguire, <damian.j.maguire@...> wrote:
Hey Dimitry, 

At a glance I'd say it's failing to find libevent and its headers. Can you check you have the correct libraries installed and located in a standard location? There should be some info on those on the wiki on GitHub. Were you able to build master previously, or is this a completely fresh checkout?

Thanks,

Damian

On Thu, 3 Mar 2016 01:03 Dmitri Fedorov, <dfedorov.solace@...> wrote:
Hello,

On CentOS 7, this is the build command:
[dfedorov@localhost OpenMAMA]$ scons middleware=avis avis_home=/opt/avis with_testtools=True with_unittest=True gtest_home=/usr

<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/avis/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/opt/avis/include -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/avis/io.c
WARNING:: mama/c_cpp/src/c/bridge/avis/io.c:32:19: fatal error: event.h: No such file or directory
 #include <event.h>
                   ^
compilation terminated.

The only "event.h" I found is the one that that is a part of qpid-proton-c-devel package:

Alright, I thought, let's build with qpid instead:

[dfedorov@localhost OpenMAMA]$ scons middleware=qpid qpid_home=/usr/include/proton
<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/qpid/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Werror -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/usr/include/proton -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/qpid/io.c
WARNING:: mama/c_cpp/src/c/bridge/qpid/io.c:54:25: error: field 'mEvent' has incomplete type
     struct event        mEvent;
                         ^
mama/c_cpp/src/c/bridge/qpid/io.c: In function 'qpidBridgeMamaIo_create':
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: error: 'EV_READ' undeclared (first use in this function)
         evtType = EV_READ;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: note: each undeclared identifier is reported only once for each function it appears in
mama/c_cpp/src/c/bridge/qpid/io.c:106:19: error: 'EV_WRITE' undeclared (first use in this function)
         evtType = EV_WRITE;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:132:5: error: implicit declaration of function 'event_set' [-Werror=implicit-function-declaration]
     event_set (&impl->mEvent,
<...>
mama/c_cpp/src/c/bridge/qpid/io.c:270:9: error: 'EV_TIMEOUT' undeclared (first use in this function)
     if (EV_TIMEOUT == type)
         ^
cc1: all warnings being treated as errors
scons: *** [objdir/mama/c_cpp/src/c/bridge/qpid/io.o] Error 1
scons: building terminated because of errors.


I could dig dipper, but I'm sure you guys know what I'm doing wrong here, please advise.

Thank you in advance!

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.
_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev
_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

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


Re: can't compile 2.4.0 branch

Dmitri Fedorov <dfedorov.solace@...>
 

Thank you, yes, "libevent-devel" was missing.

Damian, who is "Dimitry" :-)?

Regards,
Dmitri Fedorov
Software Architect
​grep -i wiki ​
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 Thu, Mar 3, 2016 at 4:45 AM, Frank Quinn <fquinn.ni@...> wrote:

Yeah you can find details on https://github.com/OpenMAMA/OpenMAMA/wiki/Building-on-Linux, but you’re missing libevent-devel.

 

Cheers,

Frank


On Thu, 3 Mar 2016 06:07 Damian Maguire, <damian.j.maguire@...> wrote:
Hey Dimitry, 

At a glance I'd say it's failing to find libevent and its headers. Can you check you have the correct libraries installed and located in a standard location? There should be some info on those on the wiki on GitHub. Were you able to build master previously, or is this a completely fresh checkout?

Thanks,

Damian

On Thu, 3 Mar 2016 01:03 Dmitri Fedorov, <dfedorov.solace@...> wrote:
Hello,

On CentOS 7, this is the build command:
[dfedorov@localhost OpenMAMA]$ scons middleware=avis avis_home=/opt/avis with_testtools=True with_unittest=True gtest_home=/usr

<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/avis/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/opt/avis/include -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/avis/io.c
WARNING:: mama/c_cpp/src/c/bridge/avis/io.c:32:19: fatal error: event.h: No such file or directory
 #include <event.h>
                   ^
compilation terminated.

The only "event.h" I found is the one that that is a part of qpid-proton-c-devel package:

Alright, I thought, let's build with qpid instead:

[dfedorov@localhost OpenMAMA]$ scons middleware=qpid qpid_home=/usr/include/proton
<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/qpid/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Werror -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/usr/include/proton -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/qpid/io.c
WARNING:: mama/c_cpp/src/c/bridge/qpid/io.c:54:25: error: field 'mEvent' has incomplete type
     struct event        mEvent;
                         ^
mama/c_cpp/src/c/bridge/qpid/io.c: In function 'qpidBridgeMamaIo_create':
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: error: 'EV_READ' undeclared (first use in this function)
         evtType = EV_READ;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: note: each undeclared identifier is reported only once for each function it appears in
mama/c_cpp/src/c/bridge/qpid/io.c:106:19: error: 'EV_WRITE' undeclared (first use in this function)
         evtType = EV_WRITE;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:132:5: error: implicit declaration of function 'event_set' [-Werror=implicit-function-declaration]
     event_set (&impl->mEvent,
<...>
mama/c_cpp/src/c/bridge/qpid/io.c:270:9: error: 'EV_TIMEOUT' undeclared (first use in this function)
     if (EV_TIMEOUT == type)
         ^
cc1: all warnings being treated as errors
scons: *** [objdir/mama/c_cpp/src/c/bridge/qpid/io.o] Error 1
scons: building terminated because of errors.


I could dig dipper, but I'm sure you guys know what I'm doing wrong here, please advise.

Thank you in advance!

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.
_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev
_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev


Re: can't compile 2.4.0 branch

Frank Quinn <fquinn.ni@...>
 

Yeah you can find details on https://github.com/OpenMAMA/OpenMAMA/wiki/Building-on-Linux, but you’re missing libevent-devel.

 

Cheers,

Frank


On Thu, 3 Mar 2016 06:07 Damian Maguire, <damian.j.maguire@...> wrote:
Hey Dimitry, 

At a glance I'd say it's failing to find libevent and its headers. Can you check you have the correct libraries installed and located in a standard location? There should be some info on those on the wiki on GitHub. Were you able to build master previously, or is this a completely fresh checkout?

Thanks,

Damian

On Thu, 3 Mar 2016 01:03 Dmitri Fedorov, <dfedorov.solace@...> wrote:
Hello,

On CentOS 7, this is the build command:
[dfedorov@localhost OpenMAMA]$ scons middleware=avis avis_home=/opt/avis with_testtools=True with_unittest=True gtest_home=/usr

<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/avis/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/opt/avis/include -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/avis/io.c
WARNING:: mama/c_cpp/src/c/bridge/avis/io.c:32:19: fatal error: event.h: No such file or directory
 #include <event.h>
                   ^
compilation terminated.

The only "event.h" I found is the one that that is a part of qpid-proton-c-devel package:

Alright, I thought, let's build with qpid instead:

[dfedorov@localhost OpenMAMA]$ scons middleware=qpid qpid_home=/usr/include/proton
<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/qpid/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Werror -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/usr/include/proton -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/qpid/io.c
WARNING:: mama/c_cpp/src/c/bridge/qpid/io.c:54:25: error: field 'mEvent' has incomplete type
     struct event        mEvent;
                         ^
mama/c_cpp/src/c/bridge/qpid/io.c: In function 'qpidBridgeMamaIo_create':
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: error: 'EV_READ' undeclared (first use in this function)
         evtType = EV_READ;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: note: each undeclared identifier is reported only once for each function it appears in
mama/c_cpp/src/c/bridge/qpid/io.c:106:19: error: 'EV_WRITE' undeclared (first use in this function)
         evtType = EV_WRITE;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:132:5: error: implicit declaration of function 'event_set' [-Werror=implicit-function-declaration]
     event_set (&impl->mEvent,
<...>
mama/c_cpp/src/c/bridge/qpid/io.c:270:9: error: 'EV_TIMEOUT' undeclared (first use in this function)
     if (EV_TIMEOUT == type)
         ^
cc1: all warnings being treated as errors
scons: *** [objdir/mama/c_cpp/src/c/bridge/qpid/io.o] Error 1
scons: building terminated because of errors.


I could dig dipper, but I'm sure you guys know what I'm doing wrong here, please advise.

Thank you in advance!

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.
_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev
_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev


Re: can't compile 2.4.0 branch

Damian Maguire <damian.j.maguire@...>
 

Hey Dimitry, 

At a glance I'd say it's failing to find libevent and its headers. Can you check you have the correct libraries installed and located in a standard location? There should be some info on those on the wiki on GitHub. Were you able to build master previously, or is this a completely fresh checkout?

Thanks,

Damian

On Thu, 3 Mar 2016 01:03 Dmitri Fedorov, <dfedorov.solace@...> wrote:
Hello,

On CentOS 7, this is the build command:
[dfedorov@localhost OpenMAMA]$ scons middleware=avis avis_home=/opt/avis with_testtools=True with_unittest=True gtest_home=/usr

<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/avis/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/opt/avis/include -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/avis/io.c
WARNING:: mama/c_cpp/src/c/bridge/avis/io.c:32:19: fatal error: event.h: No such file or directory
 #include <event.h>
                   ^
compilation terminated.

The only "event.h" I found is the one that that is a part of qpid-proton-c-devel package:

Alright, I thought, let's build with qpid instead:

[dfedorov@localhost OpenMAMA]$ scons middleware=qpid qpid_home=/usr/include/proton
<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/qpid/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Werror -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/usr/include/proton -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/qpid/io.c
WARNING:: mama/c_cpp/src/c/bridge/qpid/io.c:54:25: error: field 'mEvent' has incomplete type
     struct event        mEvent;
                         ^
mama/c_cpp/src/c/bridge/qpid/io.c: In function 'qpidBridgeMamaIo_create':
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: error: 'EV_READ' undeclared (first use in this function)
         evtType = EV_READ;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: note: each undeclared identifier is reported only once for each function it appears in
mama/c_cpp/src/c/bridge/qpid/io.c:106:19: error: 'EV_WRITE' undeclared (first use in this function)
         evtType = EV_WRITE;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:132:5: error: implicit declaration of function 'event_set' [-Werror=implicit-function-declaration]
     event_set (&impl->mEvent,
<...>
mama/c_cpp/src/c/bridge/qpid/io.c:270:9: error: 'EV_TIMEOUT' undeclared (first use in this function)
     if (EV_TIMEOUT == type)
         ^
cc1: all warnings being treated as errors
scons: *** [objdir/mama/c_cpp/src/c/bridge/qpid/io.o] Error 1
scons: building terminated because of errors.


I could dig dipper, but I'm sure you guys know what I'm doing wrong here, please advise.

Thank you in advance!

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.
_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev


can't compile 2.4.0 branch

Dmitri Fedorov <dfedorov.solace@...>
 

Hello,

On CentOS 7, this is the build command:
[dfedorov@localhost OpenMAMA]$ scons middleware=avis avis_home=/opt/avis with_testtools=True with_unittest=True gtest_home=/usr

<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/avis/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/opt/avis/include -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/avis/io.c
WARNING:: mama/c_cpp/src/c/bridge/avis/io.c:32:19: fatal error: event.h: No such file or directory
 #include <event.h>
                   ^
compilation terminated.

The only "event.h" I found is the one that that is a part of qpid-proton-c-devel package:

Alright, I thought, let's build with qpid instead:

[dfedorov@localhost OpenMAMA]$ scons middleware=qpid qpid_home=/usr/include/proton
<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/qpid/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Werror -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/usr/include/proton -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/qpid/io.c
WARNING:: mama/c_cpp/src/c/bridge/qpid/io.c:54:25: error: field 'mEvent' has incomplete type
     struct event        mEvent;
                         ^
mama/c_cpp/src/c/bridge/qpid/io.c: In function 'qpidBridgeMamaIo_create':
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: error: 'EV_READ' undeclared (first use in this function)
         evtType = EV_READ;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: note: each undeclared identifier is reported only once for each function it appears in
mama/c_cpp/src/c/bridge/qpid/io.c:106:19: error: 'EV_WRITE' undeclared (first use in this function)
         evtType = EV_WRITE;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:132:5: error: implicit declaration of function 'event_set' [-Werror=implicit-function-declaration]
     event_set (&impl->mEvent,
<...>
mama/c_cpp/src/c/bridge/qpid/io.c:270:9: error: 'EV_TIMEOUT' undeclared (first use in this function)
     if (EV_TIMEOUT == type)
         ^
cc1: all warnings being treated as errors
scons: *** [objdir/mama/c_cpp/src/c/bridge/qpid/io.o] Error 1
scons: building terminated because of errors.


I could dig dipper, but I'm sure you guys know what I'm doing wrong here, please advise.

Thank you in advance!

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.


Last Call for Bug Fixes to Include in OpenMAMA 2.4.0 RC2

Frank Quinn <f.quinn@...>
 

Hi Folks,

 

There were a few bugs reported which fixes have been put in for since OpenMAMA 2.4.0 RC1 which have now been merged (thanks to all contributors) so we’re on schedule to cut another release candidate this Thursday / Friday. If there are any new bugs to report, please raise them on github as soon as possible.

 

N.B. As this is a release candidate, only bug fixes will be considered.

 

Cheers,

Frank


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


OpenMAMA Data Quality as pluggable libs

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

Hi,

 

I've been looking at the data quality (dq) code and have some ideas on how to support multiple dq strategies.

 

Generally mama has a dq strategy built into dqstrategy.c, subscription.c, and transport.c that supports:

·         SeqNums being present from the publisher to detect gaps and request recaps.

·         SenderIds being present from the publisher and used for FT takeover.

·         Initial/Recap pre-cache to correctly order an initial/recap and updates.

·         Various config parameters for how the app should handle dq issues:

o   Transport bounces and setting subs stale.

o   Duplicate msgs.

o   When to apply pre-cache.

o   Handle initials (requiresInitial).

o   Turn on/off dq (recoverGaps).

 

In order to provide additional dq strategies it is proposed:

·         Move any code that references dq variables into dqstrategy.c. This is largely done, but there is some code in subscription.c that can be moved.

·         Make all dq structures opaque so they are only visible via methods.

·         Turn dqstrategy.c into a pluggable dq bridge, using entitlements as a model.

At this point current impl will be the default pluggable dq bridge, so the same behavior as now will be observed, and additional pluggable dq libs can be developed.

 

There is also the code in transport.c that handles transport bounces. This needs to be defined as to what service it provides for the bridges.

·         When a transport disconnects it can notify the app via a transport callback, and also each sub on the transport via stale/maybeStale.

·         When a transport reconnects it can notify the app via a transport callback, and also each sub via quality=OK, and requesting a recap.

It may be helpful to create an mDQTransport struct to hold transport-specific dq vars.

 

Attached is the beginnings of a state diagram for dq - it is a bit busy, but I think will be helpful in determining what does happen. Note that this does have paths for the code we added to send stale to subs even if dq is turned off. The red text/lines are for the 99.9% use case.

 

Any comments or ways forward please contribute.

 

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: Publisher Events Feature Documentation

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

Hi Chris,

 

I owe that, I’ll send an updated PDF to the list today/tmrw.

 

OpenMAMA group: is there a place on the wiki to store the PDF?

 

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: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Christopher Morgan
Sent: Monday, February 22, 2016 2:55 PM
To: openmama-dev@...
Subject: [Openmama-dev] Publisher Events Feature Documentation

 

Hello,

 

I was wondering where I can find up-to-date documentation for Publisher Events with transport callbacks (like a wiki page)? The current wiki page (https://github.com/OpenMAMA/OpenMAMA/wiki/Dynamic-Bridge-Loading) only refers to the publisher callbacks.

 

I have mainly been referring to the document http://lists.openmama.org/pipermail/openmama-dev/attachments/20151009/0737e7e2/attachment-0001.pdf and I was looking over the openmama 2.4.0 rc1 source code at publisher events with transport callbacks and noticed that the additions to mamaTransportTopicEvent do not have enums for MAMA_TRANSPORT_TOPIC_PUBLISH_CREATE, MAMA_TRANSPORT_TOPIC_PUBLISH_DESTROY, and MAMA_TRANSPORT_TOPIC_PUBLISH_SUCCESS. I was wondering what kind of support does publisher events have for transport callbacks?

 

Chris Morgan

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.


Publisher Events Feature Documentation

cmorgan
 

Hello,

 

I was wondering where I can find up-to-date documentation for Publisher Events with transport callbacks (like a wiki page)? The current wiki page (https://github.com/OpenMAMA/OpenMAMA/wiki/Dynamic-Bridge-Loading) only refers to the publisher callbacks.

 

I have mainly been referring to the document http://lists.openmama.org/pipermail/openmama-dev/attachments/20151009/0737e7e2/attachment-0001.pdf and I was looking over the openmama 2.4.0 rc1 source code at publisher events with transport callbacks and noticed that the additions to mamaTransportTopicEvent do not have enums for MAMA_TRANSPORT_TOPIC_PUBLISH_CREATE, MAMA_TRANSPORT_TOPIC_PUBLISH_DESTROY, and MAMA_TRANSPORT_TOPIC_PUBLISH_SUCCESS. I was wondering what kind of support does publisher events have for transport callbacks?

 

Chris Morgan


Re: OpenMAMA-2.4.0-rc1 Now Available

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

Hi,

 

Submitted one pull request for Sconscript.win to create entitlementlibraries.c.

 

With that the build works fine via scons on Windows 7 32b/64b, RHEL5 32b/64b, RHEL6 32b/64b.

 

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: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Frank Quinn
Sent: Thursday, February 18, 2016 6:37 AM
To: openmama-dev
Subject: [Openmama-dev] OpenMAMA-2.4.0-rc1 Now Available

 

Hi Folks,

 

We are pleased to announce the first release candidate for OpenMAMA 2.4.0 is now available:

 

https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-2.4.0-rc1

 

As many of you will be aware, we have been working on closing off the work required for a new OpenMAMA release for several weeks now and it is one of the biggest we have ever assembled - both in terms of features assembled and sheer quantity of new and modified lines of code.

 

With that in mind, I would appreciate everyone’s help in trying out the latest release candidate and helping weed out any bugs or unexpected behavior which may have crept in, or may be specific to your environment / bridges. At a high level, the main new functionality is in the following areas:

 

·         Qpid proton broker support

·         Several qpid proton bridge bug fixes including fixing support for using the qpid payload on non-qpid transports and vice versa

·         CentOS / RHEL 7 support

·         Timer fixes

·         Several changes to work with recent OSX

·         Publisher Events

·         Dynamic Entitlements (phase 1 - mainly focused on defining existing interface points)

·         Dynamic Bridge loading (the ability to load any middleware bridge, even if there is no reference to it in OpenMAMA code, and adding flexibility to the bride interface).

·         Ability to specify a default payload via configuration

 

With that in mind, we recommend that any testing you plan on doing pays particular attention to those areas.

 

NB for bridge developers, see updated wiki page detailing the changes required in the bridge which have changed slightly since our last notification: https://github.com/OpenMAMA/OpenMAMA/wiki/Dynamic-Bridge-Loading

 

As well as new functionality, we have also been undergoing several major operational changes since the last OpenMAMA Release:

 

·         Migrated Wiki, Issue tracking and code review all in Github out in the open (see http://github.com/OpenMAMA/OpenMAMA)

·         Continuous integration now includes Microsoft Windows builds (see http://ci.openmama.org)

·         All compiler warnings have been removed from our CentOS 6.x builds

·         All supported unit tests should now pass on Avis

 

Another focal point of this release is a general bug scrub of all outstanding issues, leading to over 100 issues of various sizes being resolved since we moved to Github less than 6 months ago.

 

Thank you all in advance for your help in testing - if you spot any issues, please follow our guidelines for raising an issue, or even better, follow our guidelines for raising a patch. Good hunting.

 

Cheers,

Frank

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-2.4.0-rc1 Now Available

Frank Quinn <fquinn.ni@...>
 

Hi Folks,


We are pleased to announce the first release candidate for OpenMAMA 2.4.0 is now available:


https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-2.4.0-rc1


As many of you will be aware, we have been working on closing off the work required for a new OpenMAMA release for several weeks now and it is one of the biggest we have ever assembled - both in terms of features assembled and sheer quantity of new and modified lines of code.


With that in mind, I would appreciate everyone’s help in trying out the latest release candidate and helping weed out any bugs or unexpected behavior which may have crept in, or may be specific to your environment / bridges. At a high level, the main new functionality is in the following areas:


  • Qpid proton broker support

  • Several qpid proton bridge bug fixes including fixing support for using the qpid payload on non-qpid transports and vice versa

  • CentOS / RHEL 7 support

  • Timer fixes

  • Several changes to work with recent OSX

  • Publisher Events

  • Dynamic Entitlements (phase 1 - mainly focused on defining existing interface points)

  • Dynamic Bridge loading (the ability to load any middleware bridge, even if there is no reference to it in OpenMAMA code, and adding flexibility to the bride interface).

  • Ability to specify a default payload via configuration


With that in mind, we recommend that any testing you plan on doing pays particular attention to those areas.


NB for bridge developers, see updated wiki page detailing the changes required in the bridge which have changed slightly since our last notification: https://github.com/OpenMAMA/OpenMAMA/wiki/Dynamic-Bridge-Loading


As well as new functionality, we have also been undergoing several major operational changes since the last OpenMAMA Release:


  • Migrated Wiki, Issue tracking and code review all in Github out in the open (see http://github.com/OpenMAMA/OpenMAMA)

  • Continuous integration now includes Microsoft Windows builds (see http://ci.openmama.org)

  • All compiler warnings have been removed from our CentOS 6.x builds

  • All supported unit tests should now pass on Avis


Another focal point of this release is a general bug scrub of all outstanding issues, leading to over 100 issues of various sizes being resolved since we moved to Github less than 6 months ago.


Thank you all in advance for your help in testing - if you spot any issues, please follow our guidelines for raising an issue, or even better, follow our guidelines for raising a patch. Good hunting.


Cheers,

Frank


Re: OpenMAMA 2.4.0

Dmitri Fedorov <dfedorov.solace@...>
 

Great, thank you very much Frank, we're looking forward to it.

Regards
Dmitri

On Mon, Feb 8, 2016 at 11:08 AM, Frank Quinn <f.quinn@...> wrote:

Hi Dmitri,

 

Yeah most of the work is done at this point so with any luck we’ll be taking the RC cut at the end of this week or the beginning of next week.

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: 08 February 2016 16:04
To: openmama-dev@...
Subject: Re: [Openmama-dev] OpenMAMA 2.4.0

 

Thank you Frank,

 

No, there is nothing, I'm just trying to understand when we are here at Solace Systems should expect this release.

 

I suppose it will take a few days to complete the remaining issues, not as few weeks, right?

 

Regards

Dmitri Fedorov

 

On Mon, Feb 8, 2016 at 10:59 AM, Frank Quinn <f.quinn@...> wrote:

Hi Dmitri,

 

Yeah that’s all that is to be completed before we take the 2.4.0 cut, why is there something that you need squeezed in?

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: 08 February 2016 15:23
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA 2.4.0

 

Hi all,

 

I'm with Solace R&D for OpenMAMA.

 

Am I right to assume that this list of open issues https://github.com/OpenMAMA/OpenMAMA/milestones/OpenMAMA-2.4.0 is all what is remained before 2.4.0 is declared, please?

 

Thank you

Dmitri Fedorov

 


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

 


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


Re: OpenMAMA 2.4.0

Frank Quinn <f.quinn@...>
 

Hi Dmitri,

 

Yeah most of the work is done at this point so with any luck we’ll be taking the RC cut at the end of this week or the beginning of next week.

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: 08 February 2016 16:04
To: openmama-dev@...
Subject: Re: [Openmama-dev] OpenMAMA 2.4.0

 

Thank you Frank,

 

No, there is nothing, I'm just trying to understand when we are here at Solace Systems should expect this release.

 

I suppose it will take a few days to complete the remaining issues, not as few weeks, right?

 

Regards

Dmitri Fedorov

 

On Mon, Feb 8, 2016 at 10:59 AM, Frank Quinn <f.quinn@...> wrote:

Hi Dmitri,

 

Yeah that’s all that is to be completed before we take the 2.4.0 cut, why is there something that you need squeezed in?

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: 08 February 2016 15:23
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA 2.4.0

 

Hi all,

 

I'm with Solace R&D for OpenMAMA.

 

Am I right to assume that this list of open issues https://github.com/OpenMAMA/OpenMAMA/milestones/OpenMAMA-2.4.0 is all what is remained before 2.4.0 is declared, please?

 

Thank you

Dmitri Fedorov

 


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

 


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


Re: OpenMAMA 2.4.0

Dmitri Fedorov <dfedorov.solace@...>
 

Thank you Frank,

No, there is nothing, I'm just trying to understand when we are here at Solace Systems should expect this release.

I suppose it will take a few days to complete the remaining issues, not as few weeks, right?

Regards
Dmitri Fedorov

On Mon, Feb 8, 2016 at 10:59 AM, Frank Quinn <f.quinn@...> wrote:

Hi Dmitri,

 

Yeah that’s all that is to be completed before we take the 2.4.0 cut, why is there something that you need squeezed in?

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: 08 February 2016 15:23
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA 2.4.0

 

Hi all,

 

I'm with Solace R&D for OpenMAMA.

 

Am I right to assume that this list of open issues https://github.com/OpenMAMA/OpenMAMA/milestones/OpenMAMA-2.4.0 is all what is remained before 2.4.0 is declared, please?

 

Thank you

Dmitri Fedorov

 


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


Re: OpenMAMA 2.4.0

Frank Quinn <f.quinn@...>
 

Hi Dmitri,

 

Yeah that’s all that is to be completed before we take the 2.4.0 cut, why is there something that you need squeezed in?

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: 08 February 2016 15:23
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA 2.4.0

 

Hi all,

 

I'm with Solace R&D for OpenMAMA.

 

Am I right to assume that this list of open issues https://github.com/OpenMAMA/OpenMAMA/milestones/OpenMAMA-2.4.0 is all what is remained before 2.4.0 is declared, please?

 

Thank you

Dmitri Fedorov

 


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


OpenMAMA 2.4.0

Dmitri Fedorov <dfedorov.solace@...>
 

Hi all,

I'm with Solace R&D for OpenMAMA.

Am I right to assume that this list of open issues https://github.com/OpenMAMA/OpenMAMA/milestones/OpenMAMA-2.4.0 is all what is remained before 2.4.0 is declared, please?

Thank you
Dmitri Fedorov


Re: Discussion Point: Dynamic Bridge Loading and Default payloads

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

For us it is mostly a support issue, in that when working with a bridge vendor it is easier if we are also using their payload.

If we are mixing bridges and payloads a vendor can quite reasonably ask “Do you still get that issue if you are using our payload?”

I did accidentally mix bridges and payloads early on, and it worked just fine, but still ….

 

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: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Frank Quinn
Sent: Thursday, February 04, 2016 5:02 AM
To: openmama-dev@...
Subject: [Openmama-dev] Discussion Point: Dynamic Bridge Loading and Default payloads

 

Hi Folks,

As brought up on a recent thread from Ben:

    2)My only observation, which is somewhat related, is that we kept the
    concept of a default payload. I think this break the whole purpose of
    OpenMama as that means mw bridge must come with their default
    payload, which is loaded by default, irrespective to the fact you are
    going to use it or not. I think this is a defect, and was hoping that we
    will take the occasion of dynamic bridge loading to get this changed.
    Although it might be a big change as it involves probably deprecating
    MamaMsg_create in favour of _createForPayload....

    I'm very keen to get feedback from the community, and particularly
    our user community about this.


I have written both enterprise applications based on OpenMAMA as well as internal OpenMAMA code, and as a user, I think mamaMsg_create() without any payload provided is very handy. I think there are a couple of reasons for this:

  1. mamaMsg_create is one of those functions which you can call from anywhere in your application. It doesn't depend on which bridge you happen to be in during a callback for or anything like that so it can literally come from anywhere. Part of its traditional appeal is specifically that the application developer doesn't need to consider which payloads are in play, and if he / she does care, there is now a separate _createForPayload method which will provide this level of control.
  2. mamaMsg_create usually does exactly what the user will want in almost every scenario. If there is only one middleware involved as it's a one sided API (i.e. a MAMA client or a MAMA publisher), the first payload recommended by the bridge is typically what the user wants to load. It's the same if there is a mid-tier (MAMA pub + sub in one MAMA instance) application where the middlewares are the same north and south.
  3. Deprecating mamaMsg_create will (I expect) have a reasonably large impact on users as a whole. In fact mamaMsg_createforPayload is actually a new method for users moving from MAMA 5 to OpenMAMA, so migrating customers will never have seen it before.

OK so that's why I think mamaMsg_create() is a nice thing to have wearing my "user hat". Here is where I think it's broken and potential solutions wearing my "bridge developer helmet":

  1. It makes the default payload library to be the first payload it finds among all payloads. This is OK in most scenarios, but I think there is a notable exception where there is a multi-bridge app present and the preferred payload for bridge 1 is not even supported by bridge 2. That means any payloads created in this application instance cannot be published by bridge 2 without additional transcoding.
    Potential Solution: Wait until all middleware bridges are loaded before selecting a default payload based on which payload bridges exist across all bridges.
  2. It has no way to be aware of optimal payload selections for each middleware bridge. An example would, again, be in a multi-bridge environment where the algorithm from #1 (let's say) is used to decide a payload compromise, but in the context where a mamaMsg_create is being called, if you always know that it will only ever be create for use with one middleware bridge, you will want to select whichever payload is preferred for that bridge.
    Potential Solution: Have an application-facing way to provide the user with the preferred payload for a given bridge object and then the user can call _createforPayload based on that value.
  3. For middleware bridges that want to support all possible payload bridges that support serialization and deserialization and possibly don't even have their own payload implementation at all (e.g. ZMQ), they may not wish to select a preference for which payload bridge to use at all.
    Potential Solution: Provide a mama.properties parameter which may be used to find supplementary, user-provided compatible bridges.

So I agree with you in that mamaMsg_create is a little broken, but I think they're all fixable without deprecating a pretty handy convenience function for most users.

Cheers,
Frank

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

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: Dynamic Bridge Loading in 2.4.0 and Bridge Backwards Compatibility

Frank Quinn <f.quinn@...>
 

Hi Folks,

On the technical committee call today there was unanimous agreement that this is the right course of action for the 2.4.0 release. However, if anyone else from the community has any objections to this, please let us know and we'll take any feedback on board.

If there are no significant objections, we will consider the issue closed on February 8th, and start actively removing the relevant backwards compatibility components in the code.

Cheers,
Frank

On 03/02/16 18:17, Frank Quinn wrote:

Hi Folks,

 

Dynamic Bridge Loading is coming in 2.4.0 and it brings with it a level of flexibility which is new to OpenMAMA’s internal bridges. It effectively allows:

 

1.       OpenMAMA to have the concept of mandatory bridge functions (thereby failing to load incompatible bridges where these bridge functions are not present).

2.       Creation of new and optional bridge functions will no longer break the bridge interface itself.

3.       Reordering of methods in each bridge will no longer break the bridge.

4.       Third parties may create OpenMAMA bridges without having to reserve enum values with the OpenMAMA project.

 

Dynamic bridge loading itself was designed with backwards compatibility in mind, but the more we spoke with users in the community, the more we understood that backwards compatibility in the bridge (as opposed to within the OpenMAMA API itself) is nowhere near as important as avoiding run time crashes due to incompatible bridges being loaded. Note that the upcoming Publisher Events framework in its current form actually depends on this functionality as it involves updating of bridge functions.

 

With that in mind, we would like to propose that the internal bridge interface (again, not to be confused with the OpenMAMA API which will remain unchanged) for OpenMAMA 2.4.x is not backwards compatible with 2.3.x.

 

The impact of this would be that each bridge vendor will need to make a few small changes to work with OpenMAMA 2.4.x as documented over at https://github.com/OpenMAMA/OpenMAMA/wiki/Dynamic-Bridge-Loading. Failure to conform with the new changes will result in OpenMAMA gracefully failing to load the bridge in question at runtime.

 

Taking this stance now will:

 

1.       Reduce the amount of code which third party bridge developers need to maintain.

2.       Ensure that we do not get hit with compatibility issues due to third party bridges not populating the bridge in a way which OpenMAMA expects in future.

3.       Allow us to retire a bunch of code rather than have a large conditional revolving around “if this is not a recent bridge”.

4.       Make it much easier for bridge developers to remain compatible with future OpenMAMA bridge changes going forward.

 

We will be discussing on a technical committee call tomorrow whether or not it’s OK to break backwards compatibility. Depending on the outcome of that, we may be sending around a note to this list offering an opportunity for other members of the community to object before pulling the trigger on this.

 

Cheers,

Frank



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

641 - 660 of 2305