Hi Mike, I have put together something that looks like it address this (I modified qpid and MamaListen locally with various sleeps to verify behaviour). Turned out to be a little trickier than I

Thanks Frank. If you could take a look at implementing this, that would be much appreciated. Mike

OK thanks Mike I thought user interaction was the primary problem but sounds like it's the finalizers. This is where the subscription stuff gets hairy because there are a few different but similar

Hi Frank, Why do we need to unlock the mutex before the deallocate call? I understand that this call destroys the lock, but with the proposed wrapper around the lock the destroy call can defer the

Classification: Public Hi Frank, Yes I will be able to review and test the PR.

Hi Igor, Erm, I think I understand the issue… If I put a PR together, can you review and verify if this fixes the issue? Cheers, Frank Frank Quinn,Cascadium | +44 (0) 28 8678 8015

Hi Mike, Could you shed some more light on what exactly the problem is here? I have had a refresher in that area, and from what I can see, I can’t think of any reason to unlock that particular

Classification: Public Hi I now seem to have successfully tested a proper fix for the issue which requires calling bridgeMamaSubscriptionMute outside of throttle locked context. All it

At first glance, that sounds like just “kicking the can down the road” — i.e., you’re still left with the problem of what to do with these wrappers such that you can tear them down in a

Thank you for your reply Bill. To get around the problem with attempting to destroy the mutex while it is locked, could we instead define our own wrapper around a recursive mutex which handles the

As far as I can tell, there’s no perfect solution here. From https://linux.die.net/man/3/pthread_mutex_destroy So you either destroy the locked mutex, which is UB, or you unlock it first. In

Hi OpenMAMA Devs, In the subscription destroy/deallocate logic, there are a couple of functions which seem to release the lock used to protect access to the subscription structure early – i.e.

Classification: Public Hi openmama team, I'd like to propose moving bridgeMamaSubscriptionMute call from mamaSubscription_deactivate_internal up in the call hierarchy to

I took an action from recent OpenMAMA Steering Committee meeting to look into MAMA plugin interface enhancement, specifically with a view to providing for a pre-subscription plugin hook that would

Yes that’s why I was suggesting this approach – it’s backwards compatible with existing bridges (we can make the bridge methods optional now where no implementation exists) and it doesn’t

I’d be cautious about that one, Frank – you’d need to think about the implications for the payload bridges because you’d need valid representations for NULL for all field types (or possibly

For the record, I’m not opposed to a “first class” null data type in principle. Json and msgpack for example have it fine. It does raise a bit of ambiguity though on how to handle a NULL value

For integers, yes, I agree. For dateTimes, as I said, you can indicate if the date part is valid or the time part is valid (hasDate()/hasTime()/setHints()). If neither flag is set, we interpret that

Thanks Nigel – I am with you now. Was not aware of the ‘setIsValidPrice()’ method. Our version of the tick42rmds bridge does not use it when translating messages received, but it could be

Still not sure I see the problem, Keith. If you receive the data as a string field and, when the transport bridge tries to map it to a mamaPrice field, the conversion fails, you should call