Even though the application has successfully completed Login, Service Directory and Dictionary phases rfa_logging reveals a number of UPDATE_RESP for Directory event messages where the State and AcceptingRequests are Empty. I have read the other ticket that mentions that these messages are because the application has not subscribed to that service and that's why RFA strips out the state and AcceptingReq section before sending the update_resp to the application, but our application is connected to that Service. What is the significance of these messages?
Thread: RFA_SESSION_ALL Session EventQueueGroup
RSSL Client Message
Msg Type: MsgType.UPDATE_RESP
Msg Model Type: DIRECTORY
Indication Flags: DO_NOT_CONFLATE
Hint Flags: HAS_RESP_TYPE_NUM
Stream Id: 2
RespTypeNum: 0 Payload: 202 bytes
MAP_ENTRY (Action.UPDATE) :
FILTER_ENTRY 1 (Action.SET) :
ELEMENT_ENTRY Name: TR_OPT
ELEMENT_ENTRY SupportsQoSRange: 0
ARRAY_ENTRY: (RT, TbT)
ELEMENT_ENTRY ddnHashEntries: 0
Based on the given information, the TREP infrastructure is the one who sends these Directory Update messages to the API. I suggest you contact the ADS support team who specialize in ADS and TREP infrastructure to verify this TREP behavior.
You can submit the ADS support ticket to their team via the https://my.thomsonreuters.com/ContactUsNew link, then select "ADS - Advanced Distribution Server" in the product section as shown below.
Here are the two I have read recently -
check the status of service --
What does an update directory message containing an empty map entry mean?
In general, when any attribute of a service changes, you will receive an update for that service. It is quite possible that the state information for that service did not change, which would explain why you didn't see any update for that attribute. You will need to look at the initial directory image you received when you logged in and look at the directory update messages to see which attribute changed.
Looking at your output, I can see some updates to TR_OPT related to Dictionaries. You may need to look at the history from when you first received the initial image to the latest to determine what specifically changed in the backend.
Note: It would be easier to view the output if you place it within a code block or capture the output in an image.
TREP does not send updates on dictionary streams. However, you will be notified if the dictionary version changes as documented within the RDM guide, Dictionary domain - usage section:
Though updates are not sent on dictionary streams, Thomson Reuters recommends that the consumer make a “streaming request” (setting OMMMsg.Indication.REFRESH) so that it is notified whenever the dictionary version changes
However, this is not related to your original question regarding directories. Because I can't see the original directory refresh nor the complete history of all the updates, I can't say for sure whether the updates are related to your dictionary or not. For now, you will need to compare what you see different between the history of updates to gain a clear understanding what has changed.
You will need to work with your market data team to determine why the backend (ADS/ADH) is generating so many source directory events and what they are. In doing some further testing with our local market data setup, I initially suspected that you may be receiving events for other services you are not interested in. In general, you should not receive any Map information about services you are not interested in. However, I did discover through testing that you will receive service events that contain only header information - nothing else unless the event is related to your service of interest. What you are seeing is odd.
I would try the following troubleshooting tests.
RFA performs the actual request on the network to receive *all* service information and simply filters those events to you based on your registered interest. Too see *all* directory events, you can turn tracing on within your config. You do this by specifying the following configuration:
<node name="yourConnection"> <map> <entry key="connectionType" value="RSSL"/> ... <entry key="traceMsgDomains" value="DIRECTORY"/> <entry key="ipcTraceFlags" value="7"/> </map> </node>
This will dump all directory-related activity to the default file: RFA_RSSL%u.log.
You can try one of the RFA Java tutorials as a simple test. I would suggest using Tutorial_08 from the downloaded package.
The ADS is most likely just passing them through and they are coming from the ADH. In the ADH you can monitor for the number of those Source Directory messages via the “adh_mon” command. On a per channel basis there is a statistic named:
sourceMessages - Count of source directory messages received for this session (RSSL only).
Here is a snapshot of one of our services and that statistic:
To get to the above screen, run “adh_mon” and then choose Source Routes and Application proxies:
Then choose the channel (route) associated with the service in question, hit return and you will see the screen with the statistics.
Receiving 40 source directory updates that contain the same thing is not normal. Hopefully the above will narrow down what they are, where and why they are happening.
Does the problem still occur in your environment? If so , could you please give us network capture file on the RSSL port from the application machine when the problem occurs? The network capture file will let us verify the incoming raw directory update messages from the ADS server.
If the application is on Linux OS, you can use the following command to capture network
tcpdump -i <interface> 'port <rssl port number>' -s 65535 -w <save file.pcap>
Please also give us the RSSL port number that the application is using.
Does the application manual request Service Directory via the API? If so, please give us a snippet code of the application can request Service Directory? We would like to check if the application set any filters or not.
I have tested the Source Directory request filter in my environment. If I subscribe only
RDMService.Filter.INFO, the application receives the directory update with empty
State and AcceptingRequests even that service is changed.
Could you please give me the network capture file on the RSSL port and a snippet code of the application that crate the Service Directory request message?
My Source Directory update is following:
LoginClient: Received DIRECTORY Response - MsgType.UPDATE_RESP MESSAGE Msg Type: MsgType.UPDATE_RESP Msg Model Type: DIRECTORY Indication Flags: DO_NOT_CONFLATE Hint Flags: HAS_ATTRIB_INFO | HAS_RESP_TYPE_NUM RespTypeNum: 0 AttribInfo Name: DIRECT_FEED Filter: 1 (INFO) Payload: 212 bytes MAP flags: MAP_ENTRY (Action.UPDATE) : flags: Key: DIRECT_FEED Value: FILTER_LIST flags: FILTER_ENTRY 1 (Action.SET) : flags: ELEMENT_LIST ELEMENT_ENTRY Name: DIRECT_FEED ELEMENT_ENTRY SupportsQoSRange: 0 ELEMENT_ENTRY Capabilities: ARRAY ARRAY_ENTRY: 5 ARRAY_ENTRY: 6 ARRAY_ENTRY: 10 ELEMENT_ENTRY QoS: ARRAY ARRAY_ENTRY: (RT, TbT) ELEMENT_ENTRY DictionariesProvided: ARRAY ARRAY_ENTRY: RWFFld ARRAY_ENTRY: RWFEnum ELEMENT_ENTRY DictionariesUsed: ARRAY ARRAY_ENTRY: RWFFld ARRAY_ENTRY: RWFEnum ELEMENT_ENTRY Vendor: Reuters ELEMENT_ENTRY IsSource: 0
Thank you for the information. The given incoming DIRECTORY Update message shows that ADS is the one who sends this non-state directory update to the API.
The application subscribes DIRECTORY interest spec with filter "Info" or "State", it means ADS will send update for the "Service Info changed" or "Service State changed" event to the API. Cold you please give us the DIRECTORY Refresh message trace log? If the Service Info does not change, you need to contact the TREP support team to help you verify why ADS sends the DIRECTORY Update message to the consumer.
Here is the Directory Refresh message -
Does the ADS send the update based on some event happening upstream(ADH and/or Edge) ? For an ADS, would a change in Service Info would be something happening on the ADH ?