Topics

MAMDA recap message format


Dmitri Fedorov <dfedorov.solace@...>
 

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:

[653]=PRICE:10.01
[654]=INT8:65
[655]=UINT32:1014500
[656]=UINT32:0
[657]=UINT16:2257
[658]=DATETIME:2017-01-04 22:55:57.428543
[681]=STRING:ask
[682]=UINT32:500
[683]=INT8:65
}, {

the second:

}, {
[653]=PRICE:10.01
[655]=UINT32:1006400
[656]=UINT32:0
[657]=UINT16:2221
[658]=DATETIME:2017-01-04 22:55:57.440543
[659]=INT16:0
}, {

[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.

T
​hank you in advance.​


Regards,
Dmitri Fedorov
Software Architect
Solace
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.


Frank Quinn <fquinn.ni@...>
 

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?

Cheers,
Frank

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:

[653]=PRICE:10.01
[654]=INT8:65
[655]=UINT32:1014500
[656]=UINT32:0
[657]=UINT16:2257
[658]=DATETIME:2017-01-04 22:55:57.428543
[681]=STRING:ask
[682]=UINT32:500
[683]=INT8:65
}, {

the second:

}, {
[653]=PRICE:10.01
[655]=UINT32:1006400
[656]=UINT32:0
[657]=UINT16:2221
[658]=DATETIME:2017-01-04 22:55:57.440543
[659]=INT16:0
}, {

[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.

T
​hank you in advance.​


Regards,
Dmitri Fedorov
Software Architect
Solace
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
Openmama-dev@....org
https://lists.openmama.org/mailman/listinfo/openmama-dev



Dmitri Fedorov <dfedorov.solace@...>
 

T
​hanks Frank,

The two different recap messages are from the same subscription at different points in time.

I've looked at updates coming it, they don't look like the recap messages at all. None of them has the counter field ​wPlNumEntries ​657 and each always has the ​
​​
wEntryId field 681 as "ask" or "bid" (one of the recap messages has this field removed).

I see wPlNumEntries added and modified in MamdaOrderBookWriter, and ​
​​
wEntryId is used do drive logic in MamdaBookAtomicListener, do we have somewhere an explanation of how these two fields are used in MAMDA?

I'll try to figure out why and how the ​
​​
wEntryId field disappears from the recap message, I suspect this is not right, would you agree?

Cheers
Dmitri


On Sat, Jan 7, 2017 at 7:49 AM, Frank Quinn <fquinn.ni@...> wrote:
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?

Cheers,
Frank

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:

[653]=PRICE:10.01
[654]=INT8:65
[655]=UINT32:1014500
[656]=UINT32:0
[657]=UINT16:2257
[658]=DATETIME:2017-01-04 22:55:57.428543
​​
[681]=STRING:ask
[682]=UINT32:500
[683]=INT8:65
}, {

the second:

}, {
[653]=PRICE:10.01
[655]=UINT32:1006400
[656]=UINT32:0
​​
[657]=UINT16:2221
[658]=DATETIME:2017-01-04 22:55:57.440543
[659]=INT16:0
}, {

[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.

T
​hank you in advance.​


Regards,
Dmitri Fedorov
Software Architect
Solace
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
Openmama-dev@...g
https://lists.openmama.org/mailman/listinfo/openmama-dev