how can I deserialize RefreshMsg and UpdateMsg ?

Hello, everyone, Due to timezone problem, I can only receive realtime quote of us market from 9:30pm in China. So I wonder if I can save RefreshMsg & UpdateMsg into somewhere, and replay these message the next bright day?

Through the ema sdk, as RefreshMsg & UpdateMsg is not copiable, the only way I can think of is to store the string value produced via toString() member method and decode each line into corresponding object member value. Is that applicable, or any better way to achieve my target ? Many thanks, expecting your reply,

Find more posts tagged with

elektron

elektron-sdk

refinitiv-realtime

rrt

elektron-message-api

ema-api

Accepted answers

chavalit-jintamalit

Hi @iscas.wang

Are you trying to replay the message for testing / development purpose ?

You can take a look at this tool. Here.

All comments

chavalit-jintamalit

Hi @iscas.wang

Are you trying to replay the message for testing / development purpose ?

You can take a look at this tool. Here.

iscas.wang

@chavalit-jintamalit

Hi, chavalit, Thanks for your suggestion. I tried the tools, but without luck, maybe i missed some steps ?

First, I use the following command to record messages

./rmdstestclient -S ELEKTRON_DD -h  10.57.44.11 -p 14002 -u user15 -ct rssl -of us.xml -ef /opt/parser/uspackage/data/tools.ric &

As rmdstestclient runs background, I terminate the tool using "kill -9" command. One question, what is the correct way to terminate the tool in order to stop recording messages? Is "kill -9" commmand OK ?

Second, I use the following command to start message server:

./sink_driven_src -S ELEKTRON_DD -Q us.xml -U 100  -N 14002 -K -ik

But I found the tools terminates by SIGKILL command after reading us.xml. I haven't done anything else than that. So How can resolve the problem ? Is it related to my way terminating rmdstestclient ?

Thanks, expecting your reply.

iscas.wang

Hi, @chavalit-jintamalit, Is there any more advice on my problem ? Thanks

zoya faberov

Hello @iscas.wang,

You need to first debug the capture, to make sure that the store at /opt/parser/uspackage/data/tools.ric is properly recorded, do you see the file recorded?

Then kill rmdstestclient.

Then start replaying the store.

iscas.wang

Hi, @zoya faberov Thanks for your advice. I tried again and found that using "kill -9" command to kill rmdsTestClient will cause the dump file incomplete with losing xml tags. The correct way is run rmdsTestClient foreground, and using Ctrl-C to terminate it. Then the dump file is complete for replay. Thanks again. also to @chavalit-jintamalit

iscas.wang

I read the manual from the infra tools, and found the following description:

sink_driven_src: source application (or traffic generator). It can also be used to evaluate update and insert latency inconjunction with rmdstestclient. It can play back data recorded by the rmdstestclient tool at rates specified by a user or at market rates.

So can I understand "at market rates" as sending played data recoded by rmdstestclient tool at the speed receiving from thomsonreuter trep precicisely at each second ? If so, which command line arguments should I use to make data replayed at market rates? @chavalit-jintamalit @zoya faberov Thanks .

zoya faberov

Hello @iscas.wang,

No, it does not.

With rmdstestclient and sink_driven_src combination, one can replay at assigned speed, or at increasing speed, which one can specify as starting, ending, and increase/delta.

If one requires more advanced replay capabilities, including "precisely as recorded originally", or "at times the speed" as recorded originally, consider ReplayService tool from TradeWeb.

iscas.wang

OK, I will take a look at ReplayService tool you advised. Many thanks. @zoya faberov

iscas.wang

Hi, @zoya faberov, when replaying quotes using sink_driven_src, I encountered such error message:

Possible overload in receiving application during the last 5 seconds.
25.00 updates/sec not sent due to buffer backlog.
Possible overload in receiving application during the last 5 seconds.
30.00 updates/sec not sent due to buffer backlog.
Possible overload in receiving application during the last 5 seconds.
27.40 updates/sec not sent due to buffer backlog.

my command specifies -U(Start update rate) with argument 30, without -M(Max update rate). Does the error indicates my consumer application is too slow to process the messages ? Thanks

zoya faberov

Hello @iscas.wang,

The overload appears to be reported not on the replay, but on the consumer.

This may result from the fact that rmdstestclient + sink_driven_src together are intended for functionality, content, and end-to-end verification, not for performance testing.

If you are verifying functionality, suggest decreasing the load, to see if it helps.

If you are looking to test performance, you need different tools, both publisher and consumer should be very performant.

EXPLORE OUR SITES