Date   

reserved fields documentation?

Dmitri Fedorov <dfedorov.solace@...>
 

Hi all,

Where do I find description of reserved fields listed in reservedfieldsimpl.h and reservedfields.c, please?

Thank you.

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

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


Re: Deferred Entitlements issue with OpenMAMA 2.4.0

Frank Quinn <fquinn.ni@...>
 

Hi Chris,

If you're going to use the noop bridge as a dev workaround, you'd need to remove the setting up of deferred entitlements from your bridge as well or had you done that already?

Yeah you're hitting code paths that none of our bridges exercise, but we'll work with you in whatever way we can to help resolve - no sinking feeling required :).

I'll await the pull request, then have a proper dive into this.

Cheers,
Frank


On Wed, 6 Apr 2016 22:10 Christopher Morgan, <Christopher.Morgan@...> wrote:

Hi Frank,

 

I have a patch to put into a pull request. I (or a colleague of mine Dmitri) will hopefully it up on git later today or early tomorrow.

 

Thanks for the workaround. Unfortunately, when I use the noop entitlements bridge I get a segmentation fault on another unit test.

The fault occurs in mamaSubscription_processWildCardMsg on a basic wild card subscription created as a part of our bridge’s inbox create. It occurs when self->mSubjectContext.mEntitlementBridge->isAllowed is accessed since mEntitlementBridge is NULL. I looked into the self->mSubjectContext  member and found that it is only set in mamaSubscription_setupBasic and mamaSubscription_getSubjectContext (and mamaSubscription_getSubjectContext is only used in mamaSubscription_processMsg). The code path for basic subscription create do not seem to call the entitlement Bridge subscription create function which I believe sets up the mSubjectContext member. Also mamaSubscription_processMsg appears to handle the entitlement bridge differently this might be useful in mamaSubscription_processWildMsg.

 

I have sinking feeling this is another issue and as it stands though I do not believe this will work as a workaround.

 

Chris Morgan

 

From: Frank Quinn [mailto:fquinn.ni@...]
Sent: April-05-16 5:57 PM
To: Christopher Morgan <Christopher.Morgan@...>
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Deferred Entitlements issue with OpenMAMA 2.4.0

 

Hi Christopher,

Good spot - yes this is definitely an issue - would appreciate any forthcoming pull requests.

Alternatively as a workaround for now, you can always disable deferred entitlements and just use the noop entitlement bridge now to unblock your testing.

For the record, longer term, I would actually like to move away from the current implementation of deferred entitlements and towards a deferred entitlement bridge which will validate bridge capabilities before permitting the entitlement bridge's enforcement mechanism to be bypassed.

 

Cheers,

Frank

 

On Tue, Apr 5, 2016 at 9:08 PM, Christopher Morgan <Christopher.Morgan@...> wrote:

Hi,

 

I’m developing a bridge with deferred entitlements using OM 2.4.0 but I keep getting an error status MAMA_STATUS_NO_BRIDGE_IMPL when using mamaSubscription_setupBasic. This occurs on any call to mamaSubscription_setupBasic, causing unit test failures and example program to error.

I used mamalistenc and got these logs before the error message:

 

2016-04-05 09:54:23:502: Entitlements checking at subscription creation deferred to myBridge bridge [0x13c6910]

2016-04-05 09:54:23:502: mamaSubscription_setupBasic(): Could not find entitlement bridge!

 

Looking at subscription.c: mamaSubscription_setupBasic it seems that if entitlements are deferred, mamaEntBridge is never set to anything other than NULL making mamaSubscription_setupBasic always return MAMA_STATUS_NO_BRIDGE_IMPL. Is this how deferred entitlements are meant to work?

 

I’m looking for confirmation that this is indeed an issue and if so, I’ll raise an issue/pull request on git hub.

 

Chris Morgan


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

 


Re: Deferred Entitlements issue with OpenMAMA 2.4.0

cmorgan
 

Hi Frank,

 

I have a patch to put into a pull request. I (or a colleague of mine Dmitri) will hopefully it up on git later today or early tomorrow.

 

Thanks for the workaround. Unfortunately, when I use the noop entitlements bridge I get a segmentation fault on another unit test.

The fault occurs in mamaSubscription_processWildCardMsg on a basic wild card subscription created as a part of our bridge’s inbox create. It occurs when self->mSubjectContext.mEntitlementBridge->isAllowed is accessed since mEntitlementBridge is NULL. I looked into the self->mSubjectContext  member and found that it is only set in mamaSubscription_setupBasic and mamaSubscription_getSubjectContext (and mamaSubscription_getSubjectContext is only used in mamaSubscription_processMsg). The code path for basic subscription create do not seem to call the entitlement Bridge subscription create function which I believe sets up the mSubjectContext member. Also mamaSubscription_processMsg appears to handle the entitlement bridge differently this might be useful in mamaSubscription_processWildMsg.

 

I have sinking feeling this is another issue and as it stands though I do not believe this will work as a workaround.

 

Chris Morgan

 

From: Frank Quinn [mailto:fquinn.ni@...]
Sent: April-05-16 5:57 PM
To: Christopher Morgan <Christopher.Morgan@...>
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Deferred Entitlements issue with OpenMAMA 2.4.0

 

Hi Christopher,

Good spot - yes this is definitely an issue - would appreciate any forthcoming pull requests.

Alternatively as a workaround for now, you can always disable deferred entitlements and just use the noop entitlement bridge now to unblock your testing.

For the record, longer term, I would actually like to move away from the current implementation of deferred entitlements and towards a deferred entitlement bridge which will validate bridge capabilities before permitting the entitlement bridge's enforcement mechanism to be bypassed.

 

Cheers,

Frank

 

On Tue, Apr 5, 2016 at 9:08 PM, Christopher Morgan <Christopher.Morgan@...> wrote:

Hi,

 

I’m developing a bridge with deferred entitlements using OM 2.4.0 but I keep getting an error status MAMA_STATUS_NO_BRIDGE_IMPL when using mamaSubscription_setupBasic. This occurs on any call to mamaSubscription_setupBasic, causing unit test failures and example program to error.

I used mamalistenc and got these logs before the error message:

 

2016-04-05 09:54:23:502: Entitlements checking at subscription creation deferred to myBridge bridge [0x13c6910]

2016-04-05 09:54:23:502: mamaSubscription_setupBasic(): Could not find entitlement bridge!

 

Looking at subscription.c: mamaSubscription_setupBasic it seems that if entitlements are deferred, mamaEntBridge is never set to anything other than NULL making mamaSubscription_setupBasic always return MAMA_STATUS_NO_BRIDGE_IMPL. Is this how deferred entitlements are meant to work?

 

I’m looking for confirmation that this is indeed an issue and if so, I’ll raise an issue/pull request on git hub.

 

Chris Morgan


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

 


Re: Deferred Entitlements issue with OpenMAMA 2.4.0

Frank Quinn <fquinn.ni@...>
 

Hi Christopher,

Good spot - yes this is definitely an issue - would appreciate any forthcoming pull requests.

Alternatively as a workaround for now, you can always disable deferred entitlements and just use the noop entitlement bridge now to unblock your testing.

For the record, longer term, I would actually like to move away from the current implementation of deferred entitlements and towards a deferred entitlement bridge which will validate bridge capabilities before permitting the entitlement bridge's enforcement mechanism to be bypassed.

Cheers,
Frank

On Tue, Apr 5, 2016 at 9:08 PM, Christopher Morgan <Christopher.Morgan@...> wrote:

Hi,

 

I’m developing a bridge with deferred entitlements using OM 2.4.0 but I keep getting an error status MAMA_STATUS_NO_BRIDGE_IMPL when using mamaSubscription_setupBasic. This occurs on any call to mamaSubscription_setupBasic, causing unit test failures and example program to error.

I used mamalistenc and got these logs before the error message:

 

2016-04-05 09:54:23:502: Entitlements checking at subscription creation deferred to myBridge bridge [0x13c6910]

2016-04-05 09:54:23:502: mamaSubscription_setupBasic(): Could not find entitlement bridge!

 

Looking at subscription.c: mamaSubscription_setupBasic it seems that if entitlements are deferred, mamaEntBridge is never set to anything other than NULL making mamaSubscription_setupBasic always return MAMA_STATUS_NO_BRIDGE_IMPL. Is this how deferred entitlements are meant to work?

 

I’m looking for confirmation that this is indeed an issue and if so, I’ll raise an issue/pull request on git hub.

 

Chris Morgan


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



Deferred Entitlements issue with OpenMAMA 2.4.0

cmorgan
 

Hi,

 

I’m developing a bridge with deferred entitlements using OM 2.4.0 but I keep getting an error status MAMA_STATUS_NO_BRIDGE_IMPL when using mamaSubscription_setupBasic. This occurs on any call to mamaSubscription_setupBasic, causing unit test failures and example program to error.

I used mamalistenc and got these logs before the error message:

 

2016-04-05 09:54:23:502: Entitlements checking at subscription creation deferred to myBridge bridge [0x13c6910]

2016-04-05 09:54:23:502: mamaSubscription_setupBasic(): Could not find entitlement bridge!

 

Looking at subscription.c: mamaSubscription_setupBasic it seems that if entitlements are deferred, mamaEntBridge is never set to anything other than NULL making mamaSubscription_setupBasic always return MAMA_STATUS_NO_BRIDGE_IMPL. Is this how deferred entitlements are meant to work?

 

I’m looking for confirmation that this is indeed an issue and if so, I’ll raise an issue/pull request on git hub.

 

Chris Morgan


Re: [Openmama-users] Deal with multiple clients and only one transport in tick42blp bridge

Tom Doust
 

Hi Nestor

 

I think there is nothing inherent in OpenMAMA that prevents you from creating and running multiple instances of the same transport. I have demonstrated this with the Tick42 TREP bridge.

 

Your second solution is not ideal because the single static transport is only going to maintain a single connection (and thread) to Bloomberg.

 

Using your first solution (which I believe is the correct way to go) , where did it fail ?

 

Best regards

 

Tom

 

From: openmama-users-bounces@... [mailto:openmama-users-bounces@...] On Behalf Of Macrux
Sent: 29 March 2016 15:52
To: openmama-dev@...; openmama-users@...
Subject: [Openmama-users] Deal with multiple clients and only one transport in tick42blp bridge

 

Hi there,

I'm working with Bloomberg and the tick42blp bridge, and I have an application which starts multiple clients, each one in a different thread, and each one can be subscribed to different subjects. I had a problem, when the second client started, it failed because the transport with that name (blp_tport) had been already created when the first client started. Then I decided to make the transport static so all clients can use the same instance, but I am not able to destroy the transport until the last client is closed, otherwise, clients that are using the transport will fail.

My question is if this is the correct approach to deal with this situation, or there is a better one?

 

Thanks in advance for any help you could give me.

Kind regards,

Nestor.


Re: Help creating generic plugin

Frank Quinn <fquinn.ni@...>
 

Hi Keith,

Matt has managed to unearth the example code I had in mind - see https://github.com/OpenMAMA/OpenMAMA/pull/159.

Cheers,
Frank

On Mon, Mar 21, 2016 at 11:44 AM, Frank Quinn <fquinn.ni@...> wrote:
Hi Keith,

Sure - please find attached. Went ahead and hit reply all here in case others are also interested.

Cheers,
Frank

On Mon, Mar 21, 2016 at 11:40 AM Keith Rudd <keith.rudd@...> wrote:

Classification: Public

Thanks for getting back on this and following up Frank.

 

The google doc doesn’t work for me – Is it possible to cut and paste the info into an e-mail?

 

Thanks,

Keith

 

From: Frank Quinn [mailto:fquinn.ni@...]
Sent: 15 March 2016 20:30
To: Keith Rudd
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Help creating generic plugin

 

Hi Keith,

Good question - I actually thought we already had this somewhere but it turns out we don't.

I think it's a sensible thing to build though, so I have raised https://github.com/OpenMAMA/OpenMAMA/issues/157 to make sure we don't forget to do so.

With respect to supporting documentation, the best thing we have at the moment is probably still the google doc referred to in Gary's 2015 post: http://lists.openmama.org/pipermail/openmama-dev/2015-May/001499.html

I'm aware that this, along with Reed's publisher events RFC doc (and others I'm sure) will need to be defragmented at some point in future, though the priority at the moment is getting 2.4.0 out the door.

 

Cheers,

Frank

 

On Mon, Mar 14, 2016 at 10:56 AM, Keith Rudd <keith.rudd@...> wrote:

Classification: Public

Is there any documentation or example code I can refer to for creating a plugin that will get called during initialization?

 

I’m referring to this call in mama.c, mama_openWithPropertiesCount()

 

                mama_initPlugins();

 

Might be useful to have an example plugin included with the source code in the same way example bridges are included.

 

Kind regards,
Keith Rudd

____________________________________________________

image001.gif

Keith Rudd
Vice President | Lead Solution Architect - Market Data Engineering

Deutsche Bank AG, Filiale London
Global Technology
6/8 Bishopsgate, EC2N 4DA London, United Kingdom
Tel. +44 20 754-53366
Mobile +44 7950687412
Email keith.rudd@...


image002.gif

 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


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

 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


Deal with multiple clients and only one transport in tick42blp bridge

macrux
 

Hi there,

I'm working with Bloomberg and the tick42blp bridge, and I have an application which starts multiple clients, each one in a different thread, and each one can be subscribed to different subjects. I had a problem, when the second client started, it failed because the transport with that name (blp_tport) had been already created when the first client started. Then I decided to make the transport static so all clients can use the same instance, but I am not able to destroy the transport until the last client is closed, otherwise, clients that are using the transport will fail.

My question is if this is the correct approach to deal with this situation, or there is a better one?

Thanks in advance for any help you could give me.

Kind regards,

Nestor.


OpenMAMA 2.4.0 Released

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

We are pleased to announce the final release of OpenMAMA 2.4.0 is now available:

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

As many of you will be aware, we have been working on this OpenMAMA release for months 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.

At a high level, the main new functionality is in the following areas:
  • Qpid proton broker support
  • It is now possible to use the qpid payload on non-qpid transports and vice versa
  • Support for Microsoft Visual Studio 2015
  • CentOS / RHEL 7 support
  • Fedora 23 support
  • A default payload type may now be enabled via configuration
  • Several changes made to work with recent OSX
  • Publisher Events now in place to allow asyncronous publish time failures to be handled
  • Dynamic entitlements now defines an entitlement interface which doesn't depend on OEA
  • Dynamic Bridge loading now allows middleware and payload bridges to work without needing to register an enum with OpenMAMA
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. If you have not made these changes since the first release candidate was cut in February, we recommend you do so ASAP to remain current with the project.


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.

A special thanks to all developers, contributors and testers who helped is getting this out door.

Cheers,
Frank


Re: Help creating generic plugin

Frank Quinn <fquinn.ni@...>
 

Hi Keith,

Sure - please find attached. Went ahead and hit reply all here in case others are also interested.

Cheers,
Frank

On Mon, Mar 21, 2016 at 11:40 AM Keith Rudd <keith.rudd@...> wrote:

Classification: Public

Thanks for getting back on this and following up Frank.

 

The google doc doesn’t work for me – Is it possible to cut and paste the info into an e-mail?

 

Thanks,

Keith

 

From: Frank Quinn [mailto:fquinn.ni@...]
Sent: 15 March 2016 20:30
To: Keith Rudd
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Help creating generic plugin

 

Hi Keith,

Good question - I actually thought we already had this somewhere but it turns out we don't.

I think it's a sensible thing to build though, so I have raised https://github.com/OpenMAMA/OpenMAMA/issues/157 to make sure we don't forget to do so.

With respect to supporting documentation, the best thing we have at the moment is probably still the google doc referred to in Gary's 2015 post: http://lists.openmama.org/pipermail/openmama-dev/2015-May/001499.html

I'm aware that this, along with Reed's publisher events RFC doc (and others I'm sure) will need to be defragmented at some point in future, though the priority at the moment is getting 2.4.0 out the door.

 

Cheers,

Frank

 

On Mon, Mar 14, 2016 at 10:56 AM, Keith Rudd <keith.rudd@...> wrote:

Classification: Public

Is there any documentation or example code I can refer to for creating a plugin that will get called during initialization?

 

I’m referring to this call in mama.c, mama_openWithPropertiesCount()

 

                mama_initPlugins();

 

Might be useful to have an example plugin included with the source code in the same way example bridges are included.

 

Kind regards,
Keith Rudd

____________________________________________________

image001.gif

Keith Rudd
Vice President | Lead Solution Architect - Market Data Engineering

Deutsche Bank AG, Filiale London
Global Technology
6/8 Bishopsgate, EC2N 4DA London, United Kingdom
Tel. +44 20 754-53366
Mobile +44 7950687412
Email keith.rudd@...


image002.gif

 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


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

 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


Re: Help creating generic plugin

Keith Rudd
 

Classification: Public

Thanks for getting back on this and following up Frank.

 

The google doc doesn’t work for me – Is it possible to cut and paste the info into an e-mail?

 

Thanks,

Keith

 

From: Frank Quinn [mailto:fquinn.ni@...]
Sent: 15 March 2016 20:30
To: Keith Rudd
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Help creating generic plugin

 

Hi Keith,

Good question - I actually thought we already had this somewhere but it turns out we don't.

I think it's a sensible thing to build though, so I have raised https://github.com/OpenMAMA/OpenMAMA/issues/157 to make sure we don't forget to do so.

With respect to supporting documentation, the best thing we have at the moment is probably still the google doc referred to in Gary's 2015 post: http://lists.openmama.org/pipermail/openmama-dev/2015-May/001499.html

I'm aware that this, along with Reed's publisher events RFC doc (and others I'm sure) will need to be defragmented at some point in future, though the priority at the moment is getting 2.4.0 out the door.

 

Cheers,

Frank

 

On Mon, Mar 14, 2016 at 10:56 AM, Keith Rudd <keith.rudd@...> wrote:

Classification: Public

Is there any documentation or example code I can refer to for creating a plugin that will get called during initialization?

 

I’m referring to this call in mama.c, mama_openWithPropertiesCount()

 

                mama_initPlugins();

 

Might be useful to have an example plugin included with the source code in the same way example bridges are included.

 

Kind regards,
Keith Rudd

____________________________________________________



Keith Rudd
Vice President | Lead Solution Architect - Market Data Engineering

Deutsche Bank AG, Filiale London
Global Technology
6/8 Bishopsgate, EC2N 4DA London, United Kingdom
Tel. +44 20 754-53366
Mobile +44 7950687412
Email keith.rudd@...


 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


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

 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


OpenMAMA-2.4.0-rc3 Now Available

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

The third (and hopefully final) release candidate for OpenMAMA 2.4.0 has just been cut and contains several new fixes put in since RC2 - see https://github.com/OpenMAMA/OpenMAMA/releases for details.

Once again, we appreciate the continued assistance from the community and the SR Labs QA team in helping us to identify and squash a few more bugs.

As discussed in other threads, we're aiming to have this release GA before the end of March.

Cheers,
Frank


Re: Openmama Documentation for subscription onDestroy

Frank Quinn <fquinn.ni@...>
 

Hi Dmitri / Duane,

OK I have the patch applied here (not yet pushed), but I'm struggling a little with what this patch accomplishes and I'm curious about whether or not your bridge is "muting" the subscription correctly when the MAMA Subscription enters the MAMA_SUBSCRIPTION_DEACTIVATING state (i.e. if the state you're hitting is fundamentally invalid to begin with).

I'll put more details on ticket then let's follow up there.

Cheers,
Frank

On Thu, Mar 10, 2016 at 4:29 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:
Hi Frank,

I'm going to echo Duane: this is a very straightforward and low risk fix, and it addresses a severe issue.

We'll make sure we follow a proper process from now on, but for this one time could you please pick it up from the patch file attached to the issue (114)?

Thank you
Dmitri


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 9 March 2016 at 16:31, Frank Quinn <fquinn.ni@...> wrote:

Hi Dmitri,


It’s not tagged for the 2.4.0 milestone as of today... why? Is it a showstopper for you guys? If so we can see if we can get it in.


To provide some context, when preparing release cuts, we look for any showstopper bugs and pull requests as well as any major features that are part of a release. Because this issue was a patch masquerading as an "issue" rather than a "pull request", it didn't make the cut at the time.


Cheers,

Frank


On Wed, Mar 9, 2016 at 4:38 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:
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-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: Help creating generic plugin

Frank Quinn <fquinn.ni@...>
 

Hi Keith,

Good question - I actually thought we already had this somewhere but it turns out we don't.

I think it's a sensible thing to build though, so I have raised https://github.com/OpenMAMA/OpenMAMA/issues/157 to make sure we don't forget to do so.

With respect to supporting documentation, the best thing we have at the moment is probably still the google doc referred to in Gary's 2015 post: http://lists.openmama.org/pipermail/openmama-dev/2015-May/001499.html

I'm aware that this, along with Reed's publisher events RFC doc (and others I'm sure) will need to be defragmented at some point in future, though the priority at the moment is getting 2.4.0 out the door.

Cheers,
Frank

On Mon, Mar 14, 2016 at 10:56 AM, Keith Rudd <keith.rudd@...> wrote:

Classification: Public

Is there any documentation or example code I can refer to for creating a plugin that will get called during initialization?

 

I’m referring to this call in mama.c, mama_openWithPropertiesCount()

 

                mama_initPlugins();

 

Might be useful to have an example plugin included with the source code in the same way example bridges are included.

 

Kind regards,
Keith Rudd

____________________________________________________



Keith Rudd
Vice President | Lead Solution Architect - Market Data Engineering

Deutsche Bank AG, Filiale London
Global Technology
6/8 Bishopsgate, EC2N 4DA London, United Kingdom
Tel. +44 20 754-53366
Mobile +44 7950687412
Email keith.rudd@...


 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.

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



Re: RC3 and GA

Frank Quinn <fquinn.ni@...>
 

Hi Dmitri,

It's looking like a third (and hopefully final) release candidate towards the end of this week and we're aiming to have the GA release out before the end of the month.

Cheers,
Frank

On Tue, Mar 15, 2016 at 6:17 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:
Hello dear all,

Would you be able to share ETA for RC3 and GA, please?

Thank you.

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

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

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



RC3 and GA

Dmitri Fedorov <dfedorov.solace@...>
 

Hello dear all,

Would you be able to share ETA for RC3 and GA, please?

Thank you.

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

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


Help creating generic plugin

Keith Rudd
 

Classification: Public

Is there any documentation or example code I can refer to for creating a plugin that will get called during initialization?

 

I’m referring to this call in mama.c, mama_openWithPropertiesCount()

 

                mama_initPlugins();

 

Might be useful to have an example plugin included with the source code in the same way example bridges are included.

 

Kind regards,
Keith Rudd

____________________________________________________



Keith Rudd
Vice President | Lead Solution Architect - Market Data Engineering

Deutsche Bank AG, Filiale London
Global Technology
6/8 Bishopsgate, EC2N 4DA London, United Kingdom
Tel. +44 20 754-53366
Mobile +44 7950687412
Email keith.rudd@...


 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


Re: Openmama Documentation for subscription onDestroy

Dmitri Fedorov <dfedorov.solace@...>
 

Hi Frank,

I'm going to echo Duane: this is a very straightforward and low risk fix, and it addresses a severe issue.

We'll make sure we follow a proper process from now on, but for this one time could you please pick it up from the patch file attached to the issue (114)?

Thank you
Dmitri


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 9 March 2016 at 16:31, Frank Quinn <fquinn.ni@...> wrote:

Hi Dmitri,


It’s not tagged for the 2.4.0 milestone as of today... why? Is it a showstopper for you guys? If so we can see if we can get it in.


To provide some context, when preparing release cuts, we look for any showstopper bugs and pull requests as well as any major features that are part of a release. Because this issue was a patch masquerading as an "issue" rather than a "pull request", it didn't make the cut at the time.


Cheers,

Frank


On Wed, Mar 9, 2016 at 4:38 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:
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-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev




Re: Openmama Documentation for subscription onDestroy

Duane Pauls <Duane.Pauls@...>
 

We're not direct users of OpenMAMA, but as someone who provides a bridge for OpenMAMA, it seems like this is a very severe problem. To run the risk of a crash when a subscription is destroyed sounds like something users of OpenMAMA wouldn't appreciate.

The fix seems relatively low risk -- we're just checking to see if the object is still valid before calling a callback on it.

So my opinion is that it would be a very good idea to try to include this in the next release.

Cheers,
Duane


Subject: Re: [Openmama-dev] Openmama Documentation for subscription
onDestroy
Message-ID:
<CAL75PSfGCH0vbd_wBpjtjx5oXotiuyKAB6tdGR8GbEMJPfHRhg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Dmitri,


It?s not tagged for the 2.4.0 milestone as of today... why? Is it a
showstopper for you guys? If so we can see if we can get it in.


To provide some context, when preparing release cuts, we look for any
showstopper bugs and pull requests as well as any major features that are
part of a release. Because this issue was a patch masquerading as an
"issue" rather than a "pull request", it didn't make the cut at the time.


Cheers,

Frank

On Wed, Mar 9, 2016 at 4:38 PM, Dmitri Fedorov <dfedorov.solace@gmail.com>
wrote:

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@solacesystems.com> 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@jpmchase.com]
*Sent:* February-01-16 10:48 AM
*To:* Duane Pauls <Duane.Pauls@SolaceSystems.com>; Christopher Morgan <
Christopher.Morgan@solacesystems.com>; openmama-dev@lists.openmama.org
*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@jpmorgan.com

Alternate Contact: CIB PIM Trading Technology Solutions NA |
CIB_PIM_Trading_Technology_Solutions_NA@jpmorgan.com





*From:* openmama-dev-bounces@lists.openmama.org [
mailto:openmama-dev-bounces@lists.openmama.org
<openmama-dev-bounces@lists.openmama.org>] *On Behalf Of *Duane Pauls
*Sent:* Thursday, January 28, 2016 1:39 PM
*To:* Christopher Morgan; openmama-dev@lists.openmama.org
*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
<http://wiki.openmama.org/index.php/OpenMAMA_Bridge_Documentation#Destroy_methods>
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@lists.openmama.org
*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@lists.openmama.org
https://lists.openmama.org/mailman/listinfo/openmama-dev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmama.org/pipermail/openmama-dev/attachments/20160309/7af2260d/attachment-0001.html>

------------------------------

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


End of Openmama-dev Digest, Vol 53, Issue 5
*******************************************


Re: Openmama Documentation for subscription onDestroy

Frank Quinn <fquinn.ni@...>
 

Hi Dmitri,


It’s not tagged for the 2.4.0 milestone as of today... why? Is it a showstopper for you guys? If so we can see if we can get it in.


To provide some context, when preparing release cuts, we look for any showstopper bugs and pull requests as well as any major features that are part of a release. Because this issue was a patch masquerading as an "issue" rather than a "pull request", it didn't make the cut at the time.


Cheers,

Frank


On Wed, Mar 9, 2016 at 4:38 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:
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-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev


621 - 640 of 2305