Hi Folks, The first version of OpenMAMA’s integration headers was merged into the development branch ready for 2018’s Q1 release last week. For application developers, this effectively

Hi Folks, I have just submitted a batch of changes which introduce OpenMAMA integration headers (so that bridges and plugins can be compiled without requiring access to OpenMAMA’s code matching

Some changes have just been added to the origin/next branch! [noreply] Added public headers for bridge and plugin projects

Some changes have just been added to the origin/next branch! [noreply] Added public headers for bridge and plugin projects

Hi Bill, Sure sounds good, though these are MAMA bridge level configurations so let's make it: mama.middleware.<id>.unload_on_close=true|false and mama.payload.<id>.unload_on_close=true|false Similar

Hi Frank: Why don’t we start over here and see if we can make some progress? If you’re OK with a solution based on a mama.properties setting, I can live with that. For the transport it seems to

I have been quite receptive to your concerns - just not your proposed solution which I think is too coarse. Checking if something exists before trying to access it within a framework is far from a

P.S. The bit about maintaining fixes etc. works both ways — once someone does a hard fork, there is less incentive for them to contribute fixes and improvements upstream. As the project maintainer

Hi Frank: Obviously I would prefer to remain as close as possible to upstream code, so forking is a last resort. That being said, you’ve been so far quite unreceptive to my concerns about crashing

On the contrary I welcome OpenMAMA forks If you want to fork and maintain all fixes etc from the upstream that's entirely your decision and part of the beauty of Open Source software. More power to

See comments inline … No, we shut down the bridges to prevent events from firing. In some cases (and certainly *not* all) that also releases resources acquired when the bridges were opened, which

@Yury: The short answer is that we can't, but we can check if a bridge is still open before attempting to access bridge dependant methods in finalisers / destructors which was my suggestion.

Hi Bill, We close the bridges because we leak memory if we dont. Imho leaking memory should be avoided where possible. In this case, its avoidable, so I don't think we should do it. If you really want

Classification: Public Hi Frank, > I would suggest a similar approach in Java - let the language specific layer deal with the language specific nuances. What is the idea on how to avoid this

HI Frank: And Happy Holidays to you too! A couple of points: I’m not aware of any changes to OpenMAMA that affect the issue, so if there are some please point me in the proper direction. The last

Classification: Public It is possible to group all mama objects (transports, subscriptions...) in one class and let it's destructor to delete them in required order. Obviously this class shouldn't let

Not sure about the other alternative? Are you expecting OpenMAMA C-API to keep track of all GC objects like shared_ptr ? *(Keeping a table of active objects for clean-up at Mama.close() may also add

Happy holidays folks! First of all (with respect to the C++ concerns), that ticket is still open - I plan on actioning it I just haven't had time yet. My suggestions were far from "don't solve it" and

Sanjeev: Thanks for the suggestion, but that is basically doing C-style manual memory management. That’s not a direction I’m interested in going — it’s the 21st century, and OpenMAMA needs

I can suggest a possible fix (by adding extra weak_ptr check) while calling Mama.close() that can avoid this problem in C11/C11++ when using shared_ptr. *(assumption is Mama.close() is not called by