From 76a6db152998cbb32de58eb1cb9d6c1ab9307a1e Mon Sep 17 00:00:00 2001 From: Gary Molloy <g.molloy@...> Date: Wed, 29 Apr 2015 13:05:23 -0400 Subject: [PATCH] [MAMAC] mamaPlugin Feature -

Yes, that looks fine, do you want me to resubmit the patch with the changes? Thanks, Reed. Reed Alpert |Corporate & Investment Bank | Market Data Services |J.P. Morgan | 4 Metrotech

Classification:Public Thanks Gavin. We’ll take a look at it then. Cheers, Keith

Hi Reed, I was just wondering if you had time to review my comments? Thanks, Gary

Hi Gary, Thanks for the patch. I had some minor comments which I marked inline below with [AA:] --Alireza

From 8eda359358a6d3bb466ede459d719c927f9d7e0e Mon Sep 17 00:00:00 2001 From: Gary Molloy <g.molloy@...> Date: Mon, 27 Apr 2015 12:45:39 -0400 Subject: [PATCH] OpenMAMA RPM Release Scripts The

Hi Keith, Thanks for your email. The plan is to try to finish up the issues for the next release by the end of this week (beginning of next week) and then cut the next branch so that the

Classification:Public Is there a planned/target release date for OpenMAMA 2.3.3 ? Regards, Keith

Thanks Gary. To give some background on this change, it’s a first pass at a plugin framework that I hope to build on to allow OpenMAMA to become much more of a flexible framework. The initial hooks

Testing Strategy:- Not middleware specific. To test this simply add the following lines to the mamapublisherc.c example application within the createPublisher() function: mamaTransport tport =

Testing Strategy:- Not middleware or O/S specific. This will require an entitled build and an entitlement server. There are 4 tests that you can run using a standard mamalistenc. For each test

Testing Strategy:- Not middleware or O/S specific. Using the attached template you can create your own plugin and load it in via your mama.properties, for example:

Hey Reed, Thank you for your patch. I have logged this asBZ-188 for you. Your patch looks good. I noticed just a few minor things: The following can just be “./src/c/mama”:

Bugzilla Ticket :- Bug 179 Testing Strategy:- Not middleware or O/S specific. This applies to building with QPID only Try building OpenMAMA against the latest version of proton (v0.8) and the

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