toggle quoted messageShow quoted text
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 reply from you was back in May.
- As the application developer I get to decide which leaks are acceptable to me, and which are not. Taking that choice away from me is not OK.
- You’re confusing and/or conflating the shutdown of the bridge libraries with the unloading of those libraries from memory.
- It is not necessary to unload the libraries in order to shut them down:
- The transport library can be shut down without being unloaded from memory.
- The payload library doesn’t need to be shut down at all, since it never fires any events.
- The only reason I can think of for dynamically unloading the libraries is to support some kind of dynamic switching of transports and/or payloads. I suspect that this feature is an example of YAGNI, but even there is a reasonable use for this feature, forcing the vast majority of applications that don’t need it to pay the price for it is a bad design decision.
Short version, it’s my application, and I get to decide how I want it to behave.
On Dec 28, 2017, at 10:33 AM, Frank Quinn <frank@...
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 was instead was more like "let's not annoy every developer of OpenMAMA by leaking memory every single time they close their application" which is what was suggested. My opinion was that if there was an alternative, we should do that. If there was no alternative, we can reassess. Fortunately in this case there is an alternative since it's possible (thanks to last year's bridge changes) to programatically check if a specific bridge is still open in the finalizer / destructor and therefore not attempt to access the bridge if it has been unloaded. This is clean, unobtrusive and lightweight.
I also suggested a configuration option to optionally leave the payload bridge open (though as mentioned in the ticket if its memory is tied to the middleware bridge, it could crash anyway).
I would suggest a similar approach in Java - let the language specific layer deal with the language specific nuances. We can avoid crashes with code changes in OpenMAMA here fairly easily.