question

Upvotes
Accepted
2 1 2 6

Stream closed without request

We use RFA 8.NET consumer

After having noticed that some of our symbols had stopped updating we enabled tracing in the application. The trace indicates the stream was closed even though it was not requested by the application ( we can observe from separate application logs). There are several of these messages for various streams.

<!-- Outgoing Message to 'gcm-ads-r1:14002' on 'localhost' interface -->
<!-- Time: 11:20:29:781 -->
<!-- rwfMajorVer="14" rwfMinorVer="0" -->
<closeMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="806" containerType="RSSL_DT_NO_DATA" flags="0x0" dataSize="0">
<dataBody>
</dataBody>
</closeMsg>

In what other scenarios would the stream be closed ( these are not Bad symbols ) when the application has not request . How do we detect that?

Thanks

Raja

treprfarfa-apistream
icon clock
10 |1500

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

The client has raised a case: 06440474

This case is still in progress, and it's being handled by @Warat B.

Upvotes
Accepted
4.4k 10 6 9

From the trace file, we could see that closed messages have been sent by the application.

A closed message can be sent by the following calls.

  • UnregisterClient(itemHandle);
    This closes the stream of the supplied itemHandle.
  • UnregisterClient();
    This close all streams that were opened for an OMMConsumer.
  • OmmConsumer.Destroy();
    This destroys the OmmConsumer event source, and in turn close all streams that were opened for the OMMConsumer.
  • Session.Release();
    This destroys the Session, and in turn destroy OMMComsumer which will close all streams.

I suggest using completion event to inform the application when the stream is closed and use this information to check what was happen at the time.

icon clock
10 |1500

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

Upvotes
7.6k 15 6 9

@rbanerjee

It may relate with parameter requestTimeout in RFA config. The default value is 45 sec. See RFA configuration section 3.1.1 RSSL Type Connection (RSSL Consumer).

Normally, RFA will generate the Timeout message once there is no response received for the item within a specific time. After that, RFA will re-request the item to recover data. The timeout can be configured by the requestTimeout configuration parameter ( 45 seconds by default).

It is possible that ADS you are connecting to, could not handle the number of requests that time. This issue should be verified by your market data engineer.

The RFA configuration may not relate with the close message you found. For testing purpose you may change it to 0 so the requests never timeout. Or you may change it to other value to see if you still get the close message in every 45 sec or not.

\Connections\Connection_RSSL\requestTimeout = 0

If the problem persists please open a new case to API support and provide full tracing log.

icon clock
10 |1500

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

Upvotes
2 1 2 6

Its not timeout. We were getting market data for more than a day since the subscription was made. Better if your API team can look at the trace log. There are a large number of subscriptions . Consumer trace after zip is around 2GB and the publisher side trace is about a GB. How do we transfer this to you?

icon clock
10 |1500

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

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

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