how do I make rmdstestclient/sink_driven_src replay L2 data
I have successfully solved the local dictionary problem and have a working system whereby I can record and replay TEL.NO L1 data.
If I connect my client app to a real feed I can recieve L2 data no problem.
However when I connect my client to my local canned data sink_driven_src, I get an error from sink-driven_src:
UPA peer component version: etaj3.4.0.G1.all.rrg|emaj3.4.0.G1.all.rrg
Sending Source Directory
Sent Source Directory
No data in cache: |7
Any idea what's going wrong?
Hello @duncan_kerr,
I would guess that the issue with replay has to do with how you record the data.
Let me include the command lines that work for me, hopefully, you will be able to use the same by adapting to your environment:
1. record_mbp.bat:
.\rmdsTestClient.exe -h myadshost -S ELEKTRON_EDGE –ct rssl -md 8 -f mbp_items.txt -dfile "C:\Program Files\Reuters\Elektron\Elektron-SDK\Ema\etc\RDMFieldDictionary" -m -X -v -of mbp_capture.txt -l mbp_capture.log
2. see the capture looks ok
3. replay_mbp.bat
.\sink_driven_src.exe -S ELEKTRON_EDGE -C 100000 -E rssl -N 14003 -U 1 -K -Q mbp_capture.txt
4. Consume MbP with test client ( in my case, port 14003 as to be distinct from other testing)
Hi Zoya - I was missing the domain spec on the record command. Im after MBO so I just added -md 7 and it works. So my record command is:
rmdstestclient -S XXXX -f file -h host -p 14002 -ct rssl -u ***** -rf 8 -I 1 -m -rbias 20 -I 1 -obf filew.bin -md 7
Zoya - my record command is:
rmdstestclient -S XXXX -f oslo.pp -h hostl -p 14002 -ct rssl -u ******* -rf 8 -I 1 -m -rbias 20 -I 1 -obf file.bin -md 7
when I replay that file & try to alter the replay speed I get a core dump from sink_driven_src. What I am trying to do is to record a L2 MBO and then replay it in a loop with a fixed replay rate. So the crash looks like this (note if I remove the -ipr 100 it stops core dumping):
# version
# ads3.4.0.L1.linux.tis.rrg/linux7_x86_64
sink_driven_src -S XXXX -v -U 1 -K -N 14002 -ik -bdf file.bin -ipr 100
Initialized RSSL library.
begin CPU time: 0.011497 sec user, 0.030660 sec system
Total number of messages processed: 980
end CPU time: 0.013251 sec user, 0.034454 sec system
.
Loaded pkts: 0 items: 44 images: 96 image_length: 0 unsol images: 0 updates: 875 update_length: 0 memory (MB): 0.565347
setup_updates: cfg_cfg_ticks_per_second=100 cfg_ticks_per_second=100 usec_per_tick=10000 updates_per_tick=0 extra_updates=1 max_updates_to_pack=10
Server fd=4: New client fd=5 newSession
Session 5 In Progress
sessionAct fd=5
RSSL Login Request from User : twsadmin
Sending Login Response
Sent Login Response Success
RSSL Source Directory request
SockOptions: TCP_NODELAY=0 SNDBUF=2626560 RCVBUF=1061488 bytes
UPA peer component version: 78fc1e330e6|78fc1e330e6
Sending Source Directory
Sent Source Directory
Received open request for TEL.NO|7 on streamId 8.
/users/is/dukerr/bin/rmdstest: line 153: 5215 Segmentation fault (core dumped) $TOOLS/sink_driven_src -S XXXX -v -U 1 -K -N 14002 -ik -bdf file.bin -ipr 100
Hi @duncan_kerr,
When you replay at one per second -U 1, it looks like your test subscriber is able to connect and see the updates?
Then you try to introduce -ipr and it crushes?
My understanding of Infra Tools is limited to common developer use cases, so let me explain as I understand it. There are two modes, we can either replay recordings, such as you were doing, or we can generate completely pre-determined bogus traffic. -ipr is for this second approach.
If you like to modify the rates while testing, I would test with -U -M -D and -T options, please see the the Infra Tools guide document.
---
I would like to add on the topic of performance testing, just in case it will be of help, that the primary intention of Infra Tools is infra verification, by market data engineers, operations, etc. For heavy performance testing, especially of level 2 data sets, it is not explicitely designed, and there is only so far that you can take infra tools in that direction. For many use cases it suffices.
If my guess is correct and you are looking to performance test, look at Perf tools that came with ESDK in Examples\PerfTools. That will take you much further, in terms of achievable publication rates, and there is code included and doc describing. If you are looking to take it even further then that, you may wish to look at ReplayService. That is a separate product designed for heavy performance testing and error condition testing.
It's a separate product, paid. Which is why I have discussed the included tools, first, and included this option, for completeness, in case you encounter the need.