Hi Folks, We are pleased to announce OpenMAMA 6.3.1 is finally here and has now propagated to Cloudsmith, Maven central etc! This is a maintenance release which fixes several outstanding bugs and intr

Hi Folks, After a successful testing period (thanks to all who were involved), we are delighted to announce the official launch the new OpenMAMA website which went live yesterday evening: https://open

Hi Folks, We (finally) have a new RC ready for testing with compiled artifacts for supported platforms – check it out: https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.1-rc1 This is a ma

Hi Folks, Quick reminder about the invitation below, and to thank everyone who has checked it out already (I can see a noticeable increase in traffic since sending this out so I know you folks are loo

Hi Folks, It is with great pleasure that I can declare that a new website is on its way. It is currently hosted at https://openmama.github.io as a preview version (the former documentation website add

Hi Folks, The default branch for OpenMAMA has now been set to “next”. Looks a little more lively already 😊 If anyone runs into any issues, let me know. Hopefully overall this will make things a little

Hi Folks, I would like to propose that we change the OpenMAMA github default git branch to “next” instead of “master”. This would mean that: When you visit our github page, you will see the latest dev

Hi Folks, Looks like a number of issues are still coming in and I have identified a few things that I want to get in myself, so I’m going to push this back 1 week to the weekend commencing 28-Aug 2020

Hi Folks, I plan on taking a cut for OpenMAMA 6.3.1 RC1 over the coming weekend (21-Aug 2020). If anyone has anything they want to submit before then please let me know so I can delay the cut if neces

Hi Folks, I have just pushed some changes into the next branch which add some changes to support: CentOS 8 Ubuntu 20.04 It also effectively drops support for the now EOL: Fedora 28 Fedora 29 Ubuntu 14

That's what the change should do - its a reference count that defers cleanup until the last reference has been released (since both the jvm GC and the bridge thread could both hit this code). It also

Hi Mike – did you have any joy with testing this one? Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

Hi Mike, Have raised https://github.com/OpenMAMA/OpenMAMA/issues/411 For follow up on this one – let’s track there for paper trail / release note reference etc. Could you add some details on the execu

Hi Igor, can you try out this branch please? https://github.com/fquinner/OpenMAMA/tree/feature/subscription-throttle-lock-scope-reduction Cheers, Frank Frank Quinn, Cascadium | +44 (0) 28 8678 8015 |

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 had a

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 are

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 | http://cascadium.

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 mutex b

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 require addi

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 in term