@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.

@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?

@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.