Re: A new "MamaResourcePool" API for OpenMAMA?

Bill Torpey

Hi Frank:

I read with interest your latest email, and certainly agree that there are ways to make OpenMAMA both easier to use (and harder to mis-use!), and more accessible to new users. We've been working on these issues since NYFIX was initially acquired by NYSE back in 2009, and have some experience (and code!) to share as a result.

For us, the biggest problem in moving our middleware stack to Mama/OpenMAMA back in the day (from Tibco Rendezvous), was the relatively poor support for setup and teardown of Mama objects. This wasn't totally surprising, as the typical use case for Mama at the time consisted of relatively long-lived publishers, with subscribers that would come and go during the day. However, in our case the subscribers (servers) tend to be the long-lived components and the publishers (clients) tended to come and go. We had a lot of problems coordinating object lifetimes, especially in a multi-threaded environment, such that we avoided memory leaks, or even worse errors such as use-after-free.

At the time, we worked with the Mama development team to create a wrapper layer called "MME" (for MAMA Managed Environment) which would manage the lifetimes of Mama event objects and remove the biggest problem in Mama: the requirement that object destruction occur only on the event dispatching thread. At the time, we hoped that MME would become part of Mama proper, but that never happened and the rights to the code were transferred to NYFIX when NYSE divested both NYFIX and SR Labs. NYFIX released the code as open-source concurrent with our release of OZ at

We've been using MME in the NYFIX Marketplace since approximately 2010; first with the commercial transport from SR/Vela, and for the past year and change with OZ (, the open-source transport that we created based on ZeroMQ.

We would be interested in working with the OpenMAMA community to extend and improve MME, and suggest that it answers several of the issues you mentioned.

One thing that MME does not address, however, is overall ease-of-use, and specifically the steep learning-curve associated with the Mama API. For that, we'd like to suggest that the community take a look at the example code included with OZ ( The example code encapsulates a lot of the "tricky bits" associated with the Mama API, enabling someone to get started quickly -- for example, see

Full disclosure: the OZ examples are exclusively C++ -- while the OZ transport itself is written in C, we prefer C++ for application-level code. The OZ examples do, however, work with other transports, specifically the (now deprecated) Qpid transport.

Both MME and OZ are tried and tested in production use, which is potentially a significant advantage. In any event, we'd be delighted to engage with the OpenMAMA community around either or both of these components to see how they could possibly address some or all of the important issues you raise. We hope the community will take the time to explore both MME and OZ, and we're very interested in any feedback.

Best Regards,

Bill Torpey

Join to automatically receive all group messages.