I have an app that uses an OmmConsumer object to submit PostMsg's to the TRCC. Until recently it was coded to send one RIC, wait for the onAckMsg message to fire, then sent the next one, and so on. I noticed that one particularly big collection (>1700 RICs) was taking 7-8 minutes to complete so I decided to change the loop to submit the RICs without waiting for the ACKs, and handle the ACKs and the status updates asynchronously, This worked initially worked well. The next time that large collection ran it completed in under 18 seconds instead of 7-8 minutes.
Today, however, I'm seeing this StatusMsg before all of the RICs have been ACK'd:
StatusMsg streamId="5" domain="System Domain" PrivateStream state="Closed / Suspect / Not entitled / 'Max message rate breached'" StatusMsgEnd
In this case all 1705 calls to OmmConsumer::submit(PostMsg(...)) completed without error, then it received about 40 good ACKs and then this message, which terminated the connection.
So two questions:
??? How do I avoid exceeding the max message rate? Is it as simple as inserting a delay in the send loop? If so, what delay? Should I pause the loop whenever there are a certain number of outstanding ACKs? If so, how many?
??? How do I recover from this error? I would need to get the connection and secure tunnel back and then resend the remaining RICs.
The maximum message rate which your ID is allowed to contribute is fixed, and your app will have to insert a delay before posting the next message.
Here is a typical login refresh message:
RefreshMsg streamId="5" domain="Login Domain" RefreshComplete privateStream state="Open / Ok / None / 'Login accepted by host **** via ****'" itemGroup="00 00" name="****" serviceId="10" Attrib dataType="ElementList" ElementList ElementEntry name="TRCE:MaxMessagesPerSecond" dataType="UInt" value="1000" ElementListEnd AttribEnd RefreshMsgEnd
If you need a higher contribution threshold, please speak with your Refinitiv account manager.