item status event after receiving a completion event

yoshiharu.iguchi
yoshiharu.iguchi Newcomer
in RFA

Hello,

When an application receives a completion event, it would be guaranteed to be the last event according to the developer's manual. But, we observed that an status message was delivered after the completion event (there was no subscription on this RIC after unregistering the handler). Is this expected behaviour? If this is the case, isEventStreamClosed is set to be true so the event would be discarded.


In addition, when the isEventStreamClosed flag is updated?

1) a client calls unregister method

2) a completion trigger is delivered (that means all subsequent events after the completion event)


Scenario #1:

call unregister handler

ItemStatus message arrived (isEventStreamClosed is true or false??)

a completion event is arrived


Scenario #2 (below UAT case):

call unregister handler

a completion event is arrived

ItemStatus message arrived (isEventStreamClosed is true or false??)


Please see the following UAT log.


--- Log message ---

19.11.2019, 13:22:51:970636 Info: MarketDataClient: Received the completion event: closure(0xe8b49cb0)

************** The completion event was delivered

19.11.2019, 13:22:51:970794 Info: MktDataSvc Status event received: IDN_SELECTFEED.600004.SHd State:Closed Status: NoResources No Quality of Service is available to process subscription, timeout expired

19.11.2019, 13:22:51:970823 Fatal: MktDataSvc Status not ok: IDN_SELECTFEED.600004.SHd State:Closed Status: NoResources No Quality of Service is available to process subscription, timeout expired

19.11.2019, 13:22:51:970857 TickData: ---- DepthTickData -Day- [600004.SHd( 0xe8b88060 )] IsStale=T UpdType=ItemClosed ----

************** The item status event was delivered

Tagged:

Best Answer

  • moragodkrit.chumsri_1
    moragodkrit.chumsri_1 LSEG
    Answer ✓

    @yoshiharu.iguchi

    Regarding the question about isEventStreamClose, RFA can close the stream in the following scenario.

    • The Event Stream is closed by RFA due to its receive status Closed. In this case, the application will receive the event with isEventStreamClosed(): true. The method isEventStreamClosed() can use to determine if the event stream had already been closed by RFA. And then the application should not call unregisterCleint because the event stream is already closed and the handle is no longer valid.


    • The item stream is closed by the application (unregisterClient() and unsubscribe()). In this case with Completion Events, the application will receive the completion event with isEventStreamClosed(): true.

    In my opinion, from your scenario when isEventStreamClosed is true you should be able to discard the events.


    Regarding your test method.

    "I had to use gdb to pause market data stream after unregistering a handler to check a message sequence around the completion event is in order as you described. Then, we saw this ItemStatus event after receiving the completion event."


    -Not sure that can you see the status message after the completion events when you leave the application running in typical application's flows rather than using the debugger pausing the whole threads?


    RFA has an internal mechanism to manage separate internal threads, which is SessionLayer and Adapter threads, so when you use the debugger to halt the entire thread and resume from the paused state, it's not a typical use-case. It could lead to an unpredictable result, and it could break RFA internal works' flows.

Answers

  • moragodkrit.chumsri_1
    moragodkrit.chumsri_1 LSEG

    @yoshiharu.iguchi

    As far as I understand, you should not receive the status after the application gets the completion event.

    • What version of RFA C++ you currently use?

    From the initial information, it seems to be the scenario that your application call unregisterClient for the item which still not receive Status or Image message back from the server. The message "No Quality of services.. " with status Closed basically generated by RFA itself for the scenario that the time that RFA waits for the response back from the server reaches the wait timeout in RFA.


    • Have you sent multiple items requests for the same item?
      Normally, if you send item requests for the same item, there will be a separate event stream with a different handle for each request. I'm not sure whether or not it is the completion event and status for a different event stream.


    • Can you add the value of the event handle (event.getHandle()) to the log so we can ensure that it's the message for the same event stream?
  • yoshiharu.iguchi
    yoshiharu.iguchi Newcomer

    moragodkrit

    > What version of RFA C++ you currently use?

    v7.6.0.L1

    I had to truncate the log files and there were lots of quote / trade updates which I didn't include. In fact, the code block has been in the production for many years. Recently, we are trying to capture a completion event. Actually, during the testing, I had to use gdb to pause market data stream after unregistering a handler to check a message sequence around the completion event is in order as you described. Then, we saw this ItemStatus event after receiving the completion event.

    > Have you sent multiple items requests for the same item?

    No

    > Can you add the value of the event handle (event.getHandle()) to the log so we can ensure that it's the message for the same event stream?

    Ok

    > As far as I understand, you should not receive the status after the application gets the completion event.

    If this is the case, the scenario #2 should not be happened (but, saw in the UAT) and please can you confirm the scenario #1. The most important point in here is either isEventStreamClosed is correctly set to the in both scenario so an application should be able to discard an event even if any subsequent event is delivered after a completion event.

Categories