What could cause state to become RSSL_DATA_SUSPECT and RSSL_STREAM_CLOSE for valid symbols?

I am working on doing some testing with a consumer application using the ETA API. I am trying to run the following test:

1. Requests are made (these are a mix of invalid requests along with requests for realtime data)

2. I then unsubscribe 2 requests

3. I make more requests (these are a mix of invalid requests, both snapshot and subscriptions, and realtime data)

4. I then unsubscribe 3 more requests

5. Requests are then made again (this time they have a mix of delayed and realtime data)

6. I then unsubscribe all open subscriptions for realtime data

7. More requests are made (mix of delayed and realtime data)

8. Try to unsubscribe an invalid symbol to make sure the application does not crash

9. Final batch of requests are made

All the unsubscribe requests are executing as planned and are not causing any issues. What is looking to cause an issue is as I make multiple requests I eventually get the following RsslState

dataState: RSSL_DATA_SUSPECT

streamState: RSSL_STREAM_CLOSED

code: RSSL_SC_NONE

text: Item was reopened under new stream.

I know the requests that are being made are able to receive the data without a problem as I tested them on there own, but when they are being made in an additional requests this state is being received. The code as of right now will treat this as an invalid symbol. Is there a better way of handling this outcome or could it be an issue with sending the requests?

Find more posts tagged with

elektron

rssl

elektron-sdk

refinitiv-realtime

elektron-transport-api

eta-api

rrt

Accepted answers

veerapath.rungruengrayubkul

timeline.zip @manning0218

Do
you mean that the scenario you replicated on BBVA.MC is to verify what I
am describing, but it is not the same as the issue you found? The
xmltracefiles.zip doesn't contain enough information. There are only
"Item was reopened..." status message on StreamId: "42" and refresh
message on StreamId: "48".

With regard to UKSR.AS, below are the timeline of messages.

10:43:26:324 - streaming requestMsg on streamId="32"

10:43:26:349 - refreshMsg on streamId="32"

10:43:30:851 - closeMsg on streamId="32"

10:44:06:345 - streaming requestMsg on streamId="52"

10:44:06:393 - refreshMsg on streamId="52"

10:44:31:376 - streaming requestMsg on streamId="66"

10:44:31:390 - statusMsg with "Item was reopened..." error on streamId="52"

10:44:31:404 - refreshMsg on streamId="66"

This
seems to be the same scenario where requests for same items are sent on
different streams ("52" and "66"). In this case, if application wants
to request snapshot data for an item which already has opened stream,
application can just sent the item request on the opened stream id. For
example, the requestMsg sent on 10:44:31:376 should be on streamId="52". Server will just sent a refresh message back for that request.

The timelines of messages for both BBVA.MC and UKSR.AS are attached.

Moreover,
I have noticed that your snapshot/non-streaming request is done
manually by application as it sent close request after receiving
refresh. You may consider using the RSSL_RQMF_STREAMING request message
flag to define if the request is streaming or non-streaming. If absent,
stream will be closed automatically after the refresh message is
received. There is no need to send close message.

For
more information about stream identification, please see the
12.1.3Stream Identification section in the Transport API 3.1 C Edition
Developers Guide document.

All comments

Lars-at-Addicticks

@manning0218. There's a 4th element in the State object besides dataState, streamState and code, namely 'text'. What does it say?

veerapath.rungruengrayubkul

@manning0218

On a connection,each data stream can be uniquely identified by the specified domainType, QoS, and msgKey contents (i.e. item name). If an application tried request same identified item under different stream id, server will responde with the "Item was reopened under new stream." status.

Please verify this scenario in your application.

Can you replicate this issue? If yes, please enable the XML tracing in your application and provide us the tracing file. To enable the XML tracing, please add the RSSL_TRACE_HEX flag in
the traceOptions.traceFlag.

RsslTraceOptions traceOptions;

rsslClearTraceOptions(&traceOptions);
traceOptions.traceMsgFileName = traceOutputFile;
traceOptions.traceFlags |= RSSL_TRACE_TO_FILE_ENABLE | RSSL_TRACE_TO_MULTIPLE_FILES | RSSL_TRACE_TO_STDOUT | RSSL_TRACE_READ | RSSL_TRACE_WRITE;
traceOptions.traceMsgMaxFileSize = 100000000;
rsslIoctl(chnl, (RsslIoctlCodes)RSSL_TRACE, (void *)&traceOptions, error);

manning0218

xmltracefiles.xml has the two files that contain BBVA.MC in which I do my initial request and then get some data. Then request it again, I was expecting to have a duplicate error occur but from what you are saying that is not the case. I also have another case similar but am not requesting the symbol again but am having the same issue. This can be seen in the xmltracefiles2.zip for UKSR.AS in which I make a snapshot/nonstream request, then a subscription/stream request, and another snapshot/nonstream. Is there a way to handle this from not occurring?

veerapath.rungruengrayubkul

timeline.zip @manning0218

With regard to UKSR.AS, below are the timeline of messages.

10:43:26:324 - streaming requestMsg on streamId="32"

10:43:26:349 - refreshMsg on streamId="32"

10:43:30:851 - closeMsg on streamId="32"

10:44:06:345 - streaming requestMsg on streamId="52"

10:44:06:393 - refreshMsg on streamId="52"

10:44:31:376 - streaming requestMsg on streamId="66"

10:44:31:390 - statusMsg with "Item was reopened..." error on streamId="52"

10:44:31:404 - refreshMsg on streamId="66"

The timelines of messages for both BBVA.MC and UKSR.AS are attached.

For
more information about stream identification, please see the
12.1.3Stream Identification section in the Transport API 3.1 C Edition
Developers Guide document.

manning0218

We are looking to always open a subscription and cache the data to keep the overhead low if it is a symbol that could an active symbol for snapshot requests with the clients. For both issues I was able to see that once a new request was made with the same symbol but different stream Id the old stream Id was closed and the new is open. We do have logic to prevent this from happening in our cache but as I have found in my test case that this is not a guarantee. Is there a way in ETA to either forward the old stream to the new for the client or have the request be considered a duplicate?

EXPLORE OUR SITES