question

Upvotes
Accepted
manning0218 avatar image
13 ●2 ●2 ●7

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?

elektronrefinitiv-realtimeelektron-sdkrrteta-apielektron-transport-apirssl
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Lars-at-Addicticks avatar image Lars-at-Addicticks

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

2 Answers

Upvotes
Accepted
veerapath.rungruengrayubkul avatar image
11.3k ●25 ●8 ●13

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.


rssl-rqmf-streaming.png (71.4 KiB)
timeline.zip (1.7 KiB)
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

manning0218 avatar image 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?

veerapath.rungruengrayubkul avatar image veerapath.rungruengrayubkul manning0218

@manning0218

ETA doesn't have feature to mange the stream, so application needs to take reponsibility to manage the request.

However, ETA ValueAdded Components have a watchlist feature which can combines multiple requests for the same item into a single stream. For more information, please see the OMM Consumer Watchlist section in the Transport API C Value Added Components Developers Guide document. The "WatchlistConsumer" example is provided in the package to leverage this feature.

ommconsumerwatchlist.png (119.4 KiB)
Upvote
veerapath.rungruengrayubkul avatar image
11.3k ●25 ●8 ●13

@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);
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

manning0218 avatar image 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?

xmltracefiles.zip (31.1 KiB)
xmltracefiles2.zip (43.1 KiB)
Click below to post an Idea Post Idea