RFA API unexpected behavior with registerClient and reissueClient

Question

Hi all, It would be great if you all could help with some pattern we are observing with the RFA API

* When two or more reissueClient close to each other, like within 0.5s,  are sent for the same client session for the same RIC , the API client's side seems to be combining some of the request. From example, 20 reissueClient were sent, but the service side only got 18 requests.

* Secondly, when we are testing out the provider demo code it seems like the value NumOfOpen is preventing the request token from been released.

* Here are the steps * we use register +register to register to the same ric
*  we use one unregister. Then we use a second unregiste
* screen shot is  the log of the provider, it seems like the provider reduced the NUm of Open to 1 only after the second unregister, and at the same time it is outputing an error.

So it seems like the numOfOpen is preventing the token been relased. Is this the expected behavior?

Jirapongse · Answer

@Zhidong_He A reissue message is typically used to request a new refresh message or modify stream properties, such as priority count and priority class. Therefore, if the calls are made in close succession, RFA may combine them. The real-time SDKs support a single stream per item and cannot open multiple streams for the same item. In RFA, however, users can call the registerClient method for the same item because RFA supports fan-out. RFA opens one stream for the item and fans out the update messages received on that stream to all registered clients. In short, all registered clients receive data from the same item stream, and RFA is responsible for distributing the update messages. When the item is request for the first time, the steam will be opened with the following request message. When the application calls the registerClient method with the same item, RFA will send a request message on the same stream with the RSSL_RQMF_STREAMING flag and the value of the increased number of the priorityCount property. When the application calls the unregisterClient method with the handle returned from the second call of the registerClient method with the same item, RFA will send a request message on the same stream with the RSSL_RQMF_NO_REFRESH flag and the value of the prioriyCount property is decreased. To support the unregisterClient method call of the same item, you may need to modify the RDMUtil::isClose method to look like this. bool isClose(UInt8 interactionType) { //return !(interactionType & ReqMsg::InitialImageFlag) && !(interactionType & ReqMsg::InterestAfterRefreshFlag); return !(interactionType & ReqMsg::InitialImageFlag); } I am not sure if the implementation of the numOfOpens variable in the Provider_Interactive example is correct, or not. You need to contact the API support team directly via Contact Premium Support to verify the example implementation. If you are a named user of that service you should see a link "Contact Premium Support" when you are logged into the product page. Otherwise, you need to contact your LSEG account team or sales team directly to register to that service. Note that RFA is a legacy API, and we do not recommend using it to develop new applications. For new development, we recommend using the Real-Time C/C++ SDK instead.

wasin.w V3 · Answer

Hello @Zhidong_He

When the RFA API receives a duplicate RIC subscription request from an application (via registerClient), it does

not
 send a new item stream request to the server. Instead, it reuses the already-opened item stream and fans out the
 data to multiple requestors (handlers). This API behavior might answer the your first question.

About the second question, I still quite do not understand. Could you please give us more information?

* More context
* The Interactive Provider shows log message about priority changing, did an application sent priority request changed via reissue? 
* The RSSL trace logs when the problem occurs
* The RFA edition and version that you are using
* etc.

EXPLORE OUR SITES