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

Unfortunately, that is not a bug, but a “feature”. The problem is that mama_close unloads both the transport and payload libraries (via dlclose on Linux). So, any access to any objects related

Classification: Public Hi team, Sorry for telling bad news in holidays but I have found a major issue with Java API - JVM may crash if GC comes after Mama.close() method. Here's code sample to

Some changes have just been added to the origin/next branch! [noreply] Added vcpkg_build option for use with vcpkg

Some changes have just been added to the origin/next branch! [fquinn.ni] Added new option for disabling runtime

Some changes have just been added to the origin/next branch! [noreply] Added visual studio 14.1 as build option site_scons/community/command_line.py Results for OpenMAMA_Snapshot_Linux CI run with

Some changes have just been added to the origin/next branch! [fquinn.ni] [MAMDA] Removing duplicated FieldUpdate structs mamda/c_cpp/src/cpp/MamdaTradeListener.cpp Results for

Some changes have just been added to the origin/next branch! [fquinn.ni] Added lex option to allow optional tool

Some changes have just been added to the origin/next branch! [fquinn.ni] [COMMON] Enhancements to support