Re: Deferred Entitlements issue with OpenMAMA 2.4.0

Frank Quinn <>

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.


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 []
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.





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



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


Join to automatically receive all group messages.