order of source directory updates and handling them correctly

tinmyo.win
tinmyo.win
in ETA

tr.txtI am making the following request using rmdsTestClient against sink_driven_source + ADS combination as provider:

./rmdstestclient -S hEDD -ct rssl -p 14001 -itemList IBM,AAPL.O,MSFT.O -X -l stdout

I received response for the symbols with groupID 1 and 2. Then I killed sink_driven_source to simulate service down or ServiceState = 0. I noticed that I received two RSSL_DMT_SOURCE updates for the two groupIds as dataState="RSSL_DATA_SUSPECT" followed by another RSSL_DMT_SOURCE update as ServiceState = 0. I have attached the XML response too.

My question is for source directory update, is it correct to assume that source directory updates are received in the order of GROUP level updates followed by SERVICE level update? Does that also mean that an Consumer application should clear all prior source directory information and react to source directory update as it comes?

Tagged:

Best Answer

  • Jirapongse
    Jirapongse
    Answer ✓

    I think that this behaviour is specific to ADS and it demonstrates the recommended practice to handle group and service level update. However, you shouldn't expect that other servers or third-party providers will follow this behaviour.

    When the service is down, one service level update is enough to change the ServiceState and the Status of all items provided by this service. The following is the description of the Status element in the Source Directory State Filter Entry.

    image

    To handle, the source directory update, the application should follow the action of the map entry and filter entry in the update message.

    For more information, please refer to the following sections in the RDM Usage Guide.

Categories