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
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?
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.
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.
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);