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

Hi Nigel, I don’t have a RIC to quote here, but the problem exists for certain data delivered over the Elektron feed, with data from contributors where we have no control over what conventions

Hi Keith – what we normally do here is use the relevant getters/setters on the Price and DateTime fields (getIsValidPrice, setIsValidPrice, HasDate, HasTime). We tell people to render blanks for

Certain other market data platforms / APIs (well, TREP) support the concept of 'blank' field values. The price and time field types actually have special blank data representations defined. This is

Hi Folks, We are pleased to announce OpenMAMA 6.3.0 is finally here! This is a bridge interface updating release which fixes several outstanding bugs and introduces some new functionality. OpenMAMA

Hi Folks, Looks like we will be wrapping this up in the middle of next week – so far no major issues reported. Cut off date is Wednesday next week. Cheers, Frank Frank

Hi Folks, RC2 now available with artefacts: https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.0-rc2 Let’s aim for a 2 week test window so please get testing! Cheers, Frank