Actually typically OpenMAMA messages are either: - always passed back back the application Or - for a small amount of types such as REFRESH, handled in the core OpenMAMA code. Other message types

BTW, I noticed the following description for MAMA_MSG_TYPE_NULL in mamaMsgType. I did not see this message type having special logic associated with it in OpenMAMA MAMC/MAMACPP. From msgtype.h:

Classification: Public Thanks Glenn, BTW what is best practice of implementing custom messages? I mean what is to return for mamaMsg_get(MdMsgType, 1), any integer which is not in standard list of

Thanks Ian, you beat me to it! First of all Yury, welcome to the list and thanks for your question. As Ian mentions one of the issues here is that you are implementing a middleware level mechanism

Classification: Public Hi Ian, Thanks for the explanation. Will do that on the application level.

Hi Yury The MAMA level refreshes are generally separate from the middleware heartbeat functionality. Specially they operate at a higher level although they can be similar in nature. Normal

Classification: Public Hi team, I'm implementing new OpenMAMA transport bridge and have a question about Advanced publishing. In my middleware a publisher keeps track of all subscribers connected to

Hi Just wondering if you go this sorted? The first request should route through to the OnNewRequst callback. As a guess I suspect that the topic is 100% correct, or possibly the callback delegates

Hi Alireza, Thanks for your patch. I have had a look at it and it looks good. I have logged it in Bugzilla for you as http://bugs.openmama.org/show_bug.cgi?id=187 Thanks, Gary Gary Molloy –

I also think the MAMA_TRANSPORT_CONNECT_FAILED language binding is applicable and missing in C++ and it should be supported for consistency with C API. For the user not valid (not in DACS) case,

Update OpenMAMA site_scons logger to include stdout for build commands as well as stderr. Hence, Windows builds details of the compile/link error (if any) from MSVS CL command-line. Signed-off-by:

If the status codes are defined in the fundamental C API then the language bindings that build on that layer must support them. This is supposed to be middleware agnostic – you can’t make

Hey Gary, Thanks for getting back to me! I've opened Bug 186 (http://bugs.openmama.org/show_bug.cgi?id=186) about this issue. I think I recreated the same leak in the qpid bridge by detaching

Hi, The context is that for the Tick42 bridge when the user is not valid (not in DACS) then the bridge sendsMAMA_TRANSPORT_CONNECT_FAILED to the transport callback, but the C++ app does not get a

Hi Sam, Thanks for your email. Typical scenarios and use cases that we have encountered, the queue is not usually destroyed that often, so we could very well have missed this during our internally

Hi Reed, On second thoughts, the callbacks are the internal MamaQueue. Possibly it may have been added for Avis [which is deprecated] let us look into it a bit more. Thanks, Adrienne

Hi Reed, Thanks for your email. In regards to the status codes - MAMA_TRANSPORT_CONNECT_FAILED - MAMA_TRANSPORT_WRITE_QUEUE_LOW_WATER_MARK - MAMA_TRANSPORT_WRITE_QUEUE_HIGH_WATER_MARK

Hi, In MamaTransport.cpp:83 the status codes MAMA_TRANSPORT_CONNECT_FAILED/MAMA_TRANSPORT_WRITE_QUEUE_LOW_WATER_MARK/MAMA_TRANSPORT_WRITE_QUEUE_HIGH_WATER_MARK are missing from the list. Java is

Hi, These are against the next branch. Fixes for Windows build using docs, testtools, and unittests. Fixes for using DOS commands instead of GNU/Linux commands. Remove reference to 'enterprise' in

Hey all, I'm tracking down a memory leak in our bridge, and I am trying to understand why mamaMsg_setMsgBuffer doesn't set the owner flag in the message. When the queue destroys the reusable