Hi Dmitri, Yeah most of the work is done at this point so with any luck we’ll be taking the RC cut at the end of this week or the beginning of next week. Cheers, Frank

Thank you Frank, No, there is nothing, I'm just trying to understand when we are here at Solace Systems should expect this release. I suppose it will take a few days to complete the remaining issues,

Hi Dmitri, Yeah that’s all that is to be completed before we take the 2.4.0 cut, why is there something that you need squeezed in? Cheers, Frank

Hi all, I'm with Solace R&D for OpenMAMA. Am I right to assume that this list of open issues https://github.com/OpenMAMA/OpenMAMA/milestones/OpenMAMA-2.4.0 is all what is remained before 2.4.0 is

For us it is mostly a support issue, in that when working with a bridge vendor it is easier if we are also using their payload. If we are mixing bridges and payloads a vendor can quite reasonably ask

Hi Folks, On the technical committee call today there was unanimous agreement that this is the right course of action for the 2.4.0 release. However, if anyone else from the community has any

Hi Folks, As brought up on a recent thread from Ben: 2)My only observation, which is somewhat related, is that we kept the concept of a default payload. I think this break the whole purpose

Thanks Ben - glad to see you're happy to take the plunge! On point #2, I was actually talking to Damian about this very point yesterday and I think I agree with the sentiment of what you're saying,

Hi Frank, I won't make it to today's call, but wanted to give some feedback : 1)I think it is perfectly OK to break backwards compatibility given: · We are all aware that the API need

Hi Folks, Dynamic Bridge Loading is coming in 2.4.0 and it brings with it a level of flexibility which is new to OpenMAMA’s internal bridges. It effectively allows: 1. OpenMAMA to have

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

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

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

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

Hi Folks, As discussed in the technical committee meeting, an example of the notifications I was considering subscribing openmama-dev to is listed below: They should only get triggered when a

Hi Folks, After a few extra days grace, I’m now declaring the feature set for OpenMAMA 2.4.0 frozen. Work will be completed on the outstanding issues to be merged into next, then the 2.4.0 code

Hi Folks, Happy new year! Now, let's round up the features / bug fixes that are going to make it into the next OpenMAMA release (2.4.0). Are there any existing issues that are not listed

Hi, MAMAJNI: MamaSubscription has unnecessary finalizer which impacts memory #94 MamaSubscription java class has a finalizer which won't be called until after destroy() is called since destroy

Hi, I’ve been working through the publisher events via transport topics callbacks with Solace dev. We have a few questions and are looking for input from the dev community. Briefly, the

Hi Folks, Happy to report that no amendments were reported as required within the required timeframe, so we may now consider this RFC closed. Thanks Reed – looking forward to the pull