We are creating ETA rssl reactor using rsslInitialize - the docs says it creates a thread under the hood.
Is there an example of using rffsRead and parsing Quote/Trades?
I think the answer to my initial question is "No" because rmds doesn't support writing single threaded code. But none of the responses below explicitly states that .
I would prefer to have a smaller thread with single response as the discussion below diverged on different topic that may not be of interest to people asking similar question
Hello @nrai,
Is Elektron-SDK 1.3 -> Cpp_C->Eta->Applications->Training->Consumer-> Module 1c
what you are looking for?
I am currently using tutorial 4. In basicMsgHandler.c, it provides
switch (msg->msgBase.msgClass)
case RSSL_MC_UP
switch (msg->msgBase.containerType)
{
case RSSL_DT_FIELD_LIST: // this is our market data
symInfo = getRMDSSym(msg);
if (symInfo)
ret = decodeFieldList(getDictionary(), dIter, symInfo, msg->updateMsg.updateType,
msg->msgBase.msgClass);
break;
}
can you pls provide parallel code in Module 1c ?
in module 1c, I see switch ( msg.msgBase.domainType ) but case RSSL_DMT_LOGIN: tells me I am not in the right region.
Will I have to figure out how to send login and request dictionary by myself?
Looks like you are not looking for an example of ETA read and parse.
Rather you are following our ETA tutorials in Tutorials -> ETA Consumer section?
The tutorial 4 = ETA Consumer - Retrieving and decoding level 1 content?
If that is the case the tutorial shows initialization with dictionary download?
I suggest either following through with the tutorial path you seem to have started, till you get to the working ETA Consumer app, or through SDK-included Applications->Training to also end up with a fully functional ETA Consumer, and not jumping back and forth. Both are self-sufficient learning paths, but they are not designed to be inter-related or mix-and-match pieces.
Sorry for the confusion. Let me give the full history /context.
I already have my application in production following tutorial4 for a few months.
Now I need a single threaded version of same.
The UPA example you showed, doesn't have example of parsing trade/quote msgs. There is one example of LOGIN msg but not sure if it is complete? Does it request dictionary etc like the tutorials and allow me to parse trade/quote and decode enumerations ? If so, I can switch to it even if I have to rewrite my applicaiton code.
My questions will always refer to the tutorials as that is what I completely understand, so please bear with me.
I would like to better understand why are you looking to move away from the tutorials code?
Both paths, dev portal tutorials and SDK learning examples show the progression of building a basic consumer app in ETA,
i.e. connection, login requesting and parsing OMM MarketPrice data. And allow to learn. They are very similar in their approach.
I think it may make sense to review the SDK examples code without migrating anything and form your own opinion if you would like to reuse some of it. Depending on what is the new requirement that is making you look to make changes.
However, in my opinion, both tutorials and examples are not quite production consumer apps, they do not include the thorough error condition handling and do not manage failover, redundancy? They are designed as step-by-step learning examples. But depends on your requirements.
I am looking to move to single threaded code. I am open to taking sample code from either tutorials or learning examples.
The ETA rssl reactor using rsslInitialize creates multiple threads (in my case it is starting one thread). How do I get rid of that thread and use my own event loop ? Which is the right sample that shows me how to do it and also parse Trade/Quote msgs ?
Right now, I have tutorial code that shows how to parse Trade/Quote and UPA training that shows how to do single threading.
Let me try to provide more information, to help you make an informed decision:
In order to use ETA, it is mandatory to call rssInitialize (or rsslInitializeEx, see ETA Dev eloperGuide).
You can see how it is implemented "under the hood" via Elektron-SDK on github.
(https://github.com/Refinitiv/Elektron-SDK/blob/master/Cpp-C/Eta/Impl/Transport/rsslImpl.c )
---
If you are looking to re-implement the library handling, and rebuilt the library locally, I do not recommend this, but we provide the means to do so, via Elektron-SDK on github- you can download and rebuild the complete code.
We do not provide any examples of this.
Most of our developer clients use the code provided for review, to see how things are implemented, not for re-implementation.
The SDK goes through the full cycle of testing on every release, and with any local modification/re-implementation, the testing of similar scale will be your organization responsibility, the other important consideration is support and maintenance, as your local modified version of the SDK will not be under Refinitiv support and maintenance, both fixes and enhancements/new released features will be your organization's responsibility to merge.
"In order to use ETA, it is mandatory to call rssInitialize (or rsslInitializeEx, see ETA Dev eloperGuide). "
Does this support single threaded invocation ? How can I use ETA in single threaded mode?
From the tutorial code comments, it seems the answer is no.
/* Initialize RSSL. The locking mode RSSL_LOCK_GLOBAL_AND_CHANNEL is required to use the RsslReactor. * RsslReactor internally utilizes multiple threads */ if (rsslInitialize(RSSL_LOCK_GLOBAL_AND_CHANNEL, &error) != RSSL_RET_SUCCESS)
If you mean in the client application- yes, you can code single thread or multiple threads. You are fully in control. The library is thread-safe and thread-aware. And the scaling techniques are described in Developers Guide.
However, the library event handling mechanism is asynchronous. I.e. updates, statuses, typically, large numbers of them, are received from sources, processed and conveyed to the application tier by the library tier, timeliness is essential, responsiveness to new requests is mandatory. Subsequently, library handling, can never be done in a single thread. Hope it makes better sense now.
"The library is thread-safe and thread-aware "
I don't need that thread. I would prefer to have my process single threaded. Are you saying it is not possible ? Is that a limitation of library ?
Threading decision should be left to users. Library cannot know how many symbols I am subscribing to.
The UPA example seemed to suggest it is possible .
This chain has taken more time than I initially thought. I would appreciate if you can please find out from the developers if they have a working example for that ? I don't mind switching to another API but ETA sounded like the most lower level.
Could you please explain what you are trying to achieve in your app?
Is there a reason why you need the library to be single-threaded?
Then we can best help you meet the requirements that you are facing.
The majority of our consumer examples are single thread, simple and ready to use.
There may be number of reasons why users may want the library to be single threaded.
I think that is beyond the scope of this discussion and unrelated .
"The majority of our consumer examples are single thread, simple and ready to use "
may be one of the reasons this discussion has gone on so long is that our understanding of "single threaded " differs. I am linux developer and this is how I find if a process is single threaded or not....(run ps to find pid)
ps -PfU crbtrd | grep RMDSpubcrbtrd 29789 1 3 99 08:55 ? 08:23:24 /apps/crb/crbtrd/cpp/cur/bin/RMDSpub
(run pstack and grep for Thread ). I am creating a thread to dispatch my events. main thread is created at start. 3rd one is created by call to rsslInitialise I believe and I would like to reuse that for dispatching my events which will be very few compared to market data events.)
pstack 29789|grep ThreadThread 3 (Thread 0x7f8c0514d700 (LWP 29796)):Thread 2 (Thread 0x7f8c0494c700 (LWP 29799)):Thread 1 (Thread 0x7f8c08b25740 (LWP 29789)):
What you say makes total sense to me.
Just in reference to asynchronous processing of every entity within Elektron API model, i.e. dictionaries, source directories, market data messages, status messages, by the library, and being able to handle extensive throughput within acceptable latency, single thread for the library is not a suitable paradigm, and so I could not immediately align your question with the API paradigm.
In terms of your use case, it makes total sense, the requirement to dispatch non-Elektron events comes up repeatedly. A popular approach is to spawn off another thread(s) for application-tier dispatch prior to starting Elektron processing, so that two run in parallel.
Please see ETA C++ Developer Guide section:
10.2.4 Transport Locking Models
for additional info on available locking mechanism configuration.
When one is designing a highly performant ETA consumer, this section helps you choose the most suitable, least restrictive but safe, locking mechanism.
thanks Zoya
Converting your comment to the answer. You are the best judge of what is the most helpful answer to your question.
However, all or some of the preceding discussion can be, potentially, of value to next developers with similar questions, so our view is to make all the relevant or connected discussion available to the members of the community.
Thank you for the helpful feedback.
Additionally, in reference you your question, would like to suggest taking at look at ETA Performance Tools examples that are part of Elektron SDK, that are included for perofrmance testing and tuning, specifically, ConsPerf = Performance Consumer example.
CondPerf example is designed to run with, or without ETA Reactor.
For further info, refer to OPEN SOURCE PERFORMANCE TOOLS GUIDE, search for parameter "-reactor" to see how the example selects to run with or without ETA reactor, and examine the included code.
Hope this helps
