Receiving two refreshes for symbol list with complete flag set to true

arun.gadade

Receiving two refreshes for symbol list with complete flag set to true
For example if we have 19022 instruments, first received 19022 (in multiple messages and one complete) and then 22 (in a message and one complete)

On arrival of refresh message , we are clearing cache and adding new symbols
The problem in on arrival of second complete refresh , we will delete 19000 instruments from cache

Jirapongse

@arun.gadade

Thank you for reaching out to us.

Does the second refresh message have the CLEAR_CACHE flag?

To verify this problem, please enable XML tracing in the API to trace all retrieved messages.

Please refer to the EMA configuration guide regarding how to enable XML tracing in the consumer.

arun.gadade

CLEAR_CACHE was false for both messages

And I am trying horizontal scaling as per this article https://developers.lseg.com/en/article-catalog/article/how-to-diagnose-and-solve-out-of-memory-issues-in-rfa-java-appli

arun.gadade

With single omm consumer I am not facing this issue. when I created multiple consumers I got this issue.

arun.gadade

@Jirapongse

Jirapongse

@arun.gadade

You are using RFA Java, not EMA. Please confirm.

We need to see the tracing data in order to identify the problem.

This developer forum is for questions on and general discussions of Refinitiv APIs. To investigate this issue, you can contact the API support team directly via Contact Premium Support.

arun.gadade

Using EMA

arun.gadade

@Jirapongse I am not able to find support at this link Contact Premium Support
Could you please provide direct link

arun.gadade

And with single consumer , on application restart , symbol list refresh keep on coming. This is intermittent issue though not on all restarts.

arun.gadade

This is happening when I subscribe to more symbolist routes.

Jirapongse

@arun.gadade

You need to be a Refinitiv Developer Connect (RDC) named user in order to access the Contact Premium Support. For more information regarding RDC, please contact your Refinitiv account team or Sales team directly.

We still need XML trace files to verify what the problem is. Please refer to the EMA configuration guide regarding how to enable XML tracing in the consumer.

You can also refer to the Enterprise Message API (EMA) - Configuration Overview article.

arun.gadade

@Jirapongse

How can achieve below throttling feature of RFA in EMA

From : TREP_RFA_Java_DeveloperGuide.pdf

14.5.8 Throttling

If a client application requests a large number of items at the same time, the requests could overflow the outgoing channel. This could cause the channel to disconnect. Additionally, the item images could be received by the consumer application about the same time. If the subscribing application cannot process the images fast enough, the network channel will overflow, causing the Slow Consumer channel to be disconnected. When the subscriber tries to recover, it will again request all of the items, thereby repeating the problem. This situation is often called thrashing.

Consumer applications can use throttling to limit the rate of requests sent to a provider to reduce the probability of thrashing occuring.

The throttling configuration is as follows:

throttleBatchCount

throttleEnabled

throttleMaxCount

throttleRequestsPerInterval

throttleTimerInterval

throttleType

Jirapongse

@arun.gadade

As far as I know, currently, EMA doesn’t provide the request throttling feature like RFA. This means that all requests registered by an application will directly be sent to server.

arun.gadade

@Jirapongse
Then is there any solution to solve this, at the application start many items are subscribed. We are facing buffer overflow which leads to request time out with one consumer client. . I tried horizontal scaling as per this article https://developers.lseg.com/en/article-catalog/article/how-to-diagnose-and-solve-out-of-memory-issues-in-rfa-java-appli
Then I got the issue which I reported.

Jirapongse

@arun.gadade

To solve the slow consumer, you need to make sure that the application callback methods return as fast as possible. You can clone the messages in the application callback methods and put the cloned messages into an internal queue which will be processed by other threads.

For the reported issue, this forum is not a proper channel to investigate this issue. I suggest contacting the API support team directly via Contact Premium Support. The API support team can verify the application code and the behavior in the EMA.