We sometimes get a ComplEventMsg (type=Event.COMPLETION_EVENT) on application startup immediately after a call to OMMConsumer.registerClient
How can I get more information about what is going on? It's not an invalid usename (it works most of the time) or an oversubscribed username (customer support can usually tell me that, but they say "we can confirm that there was no issues observed in the logs at the time of the incident."). We're using Java RFA 8.1.0.L1 library.
Hello @daniel.lipofsky ,
Thank you for your participation in the forum.
Is one of the replies below satisfactory in resolving your query?
If yes, please click the 'Accept' text next to the appropriate 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
I have checked the release notes for rfaj8.2.1.L1 and cannot see any OMMConsumer + Login related issues reported/fixed since 8.1.0.L1
Completion events are generated to inform the Application that the stream has been closed and therefore you should not expect any further events on that stream.
There are two ways in which an event stream can be closed:
• The application closes the stream via unregisterClient() call to RFA.
• The application receives an event that closes the stream.
Assuming you are not calling unregisterclient, the other explanation is that the stream is being closed off by the server and the application receives a close event.
If you are able to recreate this relatively easily, then you could enable the low-level IpcTrace in RFA Java, so that we can confirm if the Login stream is indeed being closed off by the server.
See the accepted answer in the post below for details on how to enable the low-level trace.
Null Payload in OmmMsg - Forum | Refinitiv Developer Community
I am not able to recreate on-demand. How else can I get information about a ComplEventMsg
Unless you are able to capture the low-level trace of the completion event, it is not possible to confirm if the stream is being closed off by the server.
Are you logging all the Status Information received by the application for all related events e.g. connection events, the Login Resp Msg etc. You can see an example of this in the com.reuters.rfa.example.omm.cons example packaged with RFA Java in the Examples\com\reuters\rfa\example\omm\cons folder.
The output from the above may help shed some more light on your scenario.
It looks like our client is based on Examples/com/reuters/rfa/example/omm/cons/LoginClient.java (although probably a version from many years ago).
I see we get 3 messages on failure
OMMItemEvent with OPEN, SUSPECT, NONE, "All connections pending", but this looks identical to the message we receive before a success.OMMItemEvent with isFinal flag.ComplEventMsg with no useful information.We were logging as much detail as we could from the 1st and 3rd ones but no real details from the 2nd, and that appears to be where all the useful information was. After adding full details from that message (and forcing an error by overusing the ID) I was able to see CLOSED, SUSPECT, DACS_MAX_LOGINS_REACHED, "Access Denied-already using position 100.100.173.119".
But the error I got a few days ago was not caused by overusing the ID or using a bad ID, and I can't go back in time to add the logging. Do you have any idea what else can cause a completion event?
Are you connecting to an internal ADS or to our cloud using LPC- I assume from the above DACS message that you are connecting to an internal ADS?
Also, has this just started happening recently or has this been an ongoing issue for an extended period of time?
Unfortunately without any logging/trace etc, there is no way to confirm why your Login stream was closed off.
There is always a small possibility that you are encountering a bug in RFA Java - but we would need evidence to confirm this and currently, the latest RFA Java Releases notes have no mention of any similar bug being reported and fixed in the more recent releases.
Internal. It happened twice in a row one morning, but no other time that I am aware of.
Thanks for confirming. If that is the case, I would refer you back to your internal Market Data team. As mentioned previously, Assuming you are not calling unregisterclient, the other explanation is that the stream is being closed off by the server and the application receives a close event.
They could always try reaching out to the Refinitiv RTDS support team for any other possible guidance on diagnosing the cause of the above.
Your internal Market Data team can create a ticket with the RTDS support team for further assistance in diagnosing the issue from an ADS/RTDS perspective via My.Refinitiv.
Who does "Your internal Market Data team" refer to? Are you talking about me?
My understanding from the posts above was that you are a developer at your organisation using your internal ADS servers - which are usually administered/managed by a separate Market Data team.
However, if I am mistaken and you are the ADS admin etc then you can reach out to our RTDS support team for ADS related support - the moderators etc on this forum are not RTDS experts.
We do not have a separate team for that. I started out by reaching out to the Refinitiv RTDS support team, and they said I needed to come here instead.
Thanks - I managed to find the case and contacted the case owner, but he has been out of the office since yesterday. So, I have now contacted his manager asking if they can assist you with server-side diagnostics.
I have been discussing with the RTMDS support team and it would appear there may be issues with your ADS deployment/configuration - with your ADS disconnecting from our upstream servers.
Thanks for confirming.
As mentioned before without any low-level RFA trace etc there is nothing from the API perspective which would help us identify why you may be getting these login stream closed events.
Therefore, you would need to work with the RTMDS team + whoever manages your hosted ADS servers to identify why the application is being logged out from your ADS servers.
We do not have any hosted ADS servers. Our app uses Java RFA 8.1.0.L1 to connect directly to your ADS servers.
This is a private post
I had been advised by our RTMDS support team that your application connects to your ADS inside your AWS which then connects to our managed ADS as per the RTMDS service.
They have also observed that your ADS are frequently being disconnected from our ADS because they are failing to keep pace with the rate of data being published and thereby our ADS is forced to disconnect your ADS.
If the above is incorrect and you are connecting directly to the RTMDS service - then you will need to continue to work with the RTMDS team to diagnose why your application is being logged out / disconnected from our ADS servers.
Based on the information I received from the RTMDS team (and if your application is connecting directly to our ADS) then the most likely explanation is that your application is a 'slow consumer' during the startup period and cannot cope with the volume of data the ADS is publishing in response to your subscription requests and therefore the ADS is disconnecting your application when its buffer is full. IF this is the case, you could try modifying your application to pace the initial subscriptions, so that it does not become overwhelmed with the high volume of data.
Other than the above comments, from an API perspective, without any low-level trace etc, there is no information on the basis of which we could advise or speculate as to why your application is being disconnected.
I understand that you are in discussion with your account team regards help with diagnosing your issues - I have offered the support team the option of my joining the calls if that helps.
