Re: MAMDA recap message format

Frank Quinn <>

Hi Dmitri,

Best place to start would be for the updates coming in. Odds are you'll find these fields are getting populated from the data source containing each delta rather than from within MAMDA itself, or that data types are different in multiple sources causing mixed results or something like that.

Were the two different recap messages you specified from two different subscription or at different points in time from the same subscription?


On Thu, Jan 5, 2017 at 7:52 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:
Hi all,

I'm investigating an issue in a Solace proprietary product that uses an instance of MamdaOrderBookListener to keep track of orders and to populate recap messages.

During the investigation I've come across two different formats for recap messages coming from the MamdaOrderBook->populateRecap(MamaMsg& recapMsg) call: one has ask/bid strings and the other does not.

Where should I dig to find out why and how this happens?

In my test case the publisher generates eight price levels (four asks and for bids), and after a few tens of thousand messages, the first recap message format I see is:

[658]=DATETIME:2017-01-04 22:55:57.428543
}, {

the second:

}, {
[658]=DATETIME:2017-01-04 22:55:57.440543
}, {

[657] is the entry count wPlNumEntries, [681], [682] and [683] are wEntryId, wEntrySize and wEntryAction, and [659] (that is missing from the first recap message format) is wPlNumAttach.

​hank you in advance.​

Dmitri Fedorov
Software Architect
Ottawa, ON Canada

Solace Corporation accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Corporation.

Openmama-dev mailing list

Join { to automatically receive all group messages.