Hi - I am trying to recreate a slow RMDS consumer scenario we have seen using EMA Java 3.6.0. I can repeat all the channel and ticker status messages, but in one instance we saw this status message:
Received status msg: text:Slow Consumer, statusCode:None, data:Ok, stream:Open
do you recognize this message. When would we expect to see it, exactly?
Hello @duncan_kerr ,
Thank you for your participation in the forum.
Were you able to learn more of the cause?
Is the reply below satisfactory in resolving your query?
If yes please click the 'Accept' text next to the reply. This will guide all community members who have a similar question. Otherwise please post again offering further insight into your question.
Thanks,
-AHS
Please be informed that a reply has been verified as correct in answering the question, and has been marked as such.
Thanks,
AHS
Hello @duncan_kerr ,
Please refer to this previous discussion thread on A27.
However, in my observation, this discussion's focus seems to have moved away from EMA development, and into infrastructure configuration, and likely configuration related issues.
It may be that there is a local configuration issue, or tuning is required, but this forum is intended and best able to help with general API usage questions, not really equipped to help diagnose and troubleshoot infra configuration issues.
Suggest to report the errors that you are observing to your local market data admin/group in charge of the infra, hopefully they can address/help explain the happenings.
Hello @duncan_kerr ,
"Slow consumer" problem, referring to a consumer that is not handling the update traffic in a timely manner, and causing the buffers overflow, is detected by the infra. It often results in disconnects, which are very visible, highly undesirable and usually are the first focus.
If there was no disconnect, then the situation that you have observed was likely not as severe, and might have resulted in "slow consumer" warning, but without next being a disconnect from the infra. If there was a consequent disconnect, that would make the scenario common.
I would say a way to recreate a slow consumer scenario in general, it to make on message callbacks long and slow, "hang on" to callbacks, so the callbacks don't return, by putting delays or sleeps inside the callbacks. This should help to reproduce the slow consumer problem in general, as I understand you are looking to reproduce and to capture, if not this specific message.
Hi Zoya - we also see the following message in our application, which was possibly a slow c. Can you explain when we'd expect to see this message? I suspect its a problem with our resubscription logic, but if you have seen the "data was lost" message before it'd be of interest.
SubscriptionStatus{subscriptionState=FAILURE, subscriptionMessage=UNKNOWN Subscription terminated: Data was lost for this security}
Hi Zoya - here's another message from the same period, would you be able to explain? Is there a reference to these error messages I can access?
A27: Synchronization Error. Recalling.
