Yeah, as Ian points out, this entirely depends on whether it’s basic or market data subscriptions. For heartbeats I was originally assuming basic, but it’ll depend on the answer to my question in

Hi Just to clairify. If it’s a marketdata subscription (ie MamaSubscription) then STATUS and TYPE are required fields. If they are not in the message the message will be dropped. For basic

Hi Glenn Are you saying that if a message doesn't carry the mdMsgType field then the OpenMAMA layer just passes it through to the client application. I hadn’t actually realised that ! I sort of

Hi Tom, I’m not sure what distinguishes the messages you suggest from any other kind of application messages, which don’t even need to have a message type. The ANK/NAK messages you suggest look

Although I can think of many reasons why this would be a bad idea, it might be worth considering defining some MAMA_MSG_TYPE_PLATFORM This would allow bridge developers to deliver custom stuff to

Hi I would have to agree with Glenn here, it seems that these kind of heartbeat messages should be internal to the bridge and not passed up to MAMA and as such probably should not be represented in

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