question

Upvotes
Accepted
RicknBaker avatar image
38 ●1 ●0 ●5

RFA.NET - ADS Sending Close Message

Hi all.

I have a .Net Provider and Consumer happily chatting to each other over TREP using Generic Messages. Both sides are implemented with ValueAdd.

Before they start exchanging messages, I establish the stream with a request / response handshake as documented. I'm setting InitialImage | InterestAfterRefresh which I thought would keep the stream open. However, I've noticed that after a period of inactivity, my Consumer seems to send a magic closeMsg:

<!-- Outgoing Message to 'xxxxx:14002' on 'localhost' interface --> (server name removed for security)

<!-- Time: 14:21:38:003 -->

<!-- rwfMajorVer="14" rwfMinorVer="0" -->

<closeMsg domainType="202" streamId="3" containerType="RSSL_DT_NO_DATA" flags="0x0" dataSize="0">

<dataBody> </dataBody>

</closeMsg>

There's nowhere in my code where I submit a close message, so I guess it's something within the RFA library that creates this message.

When I receive this at my Provider, I assume the Consumer has shut down and so I stop chatting:

<!-- Incoming Message from 'xxxxx' on 'localhost' interface -->

<!-- Time: 14:21:38:047 -->

<!-- rwfMajorVer="14" rwfMinorVer="0" -->

<closeMsg domainType="202" streamId="4384855" containerType="RSSL_DT_NO_DATA" flags="0x0" dataSize="0">

<dataBody> </dataBody>

</closeMsg>

This is not what I want! So how can I suppress this mysterious Close Message that originates from my Consumer? Or failing that, is there any way to differentiate between a valid close message sent when the Consumer shuts down and this spurious one?

Thanks

Rick

elektronrefinitiv-realtimetreprfamessage
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.

4 Answers

Upvote
Accepted
RicknBaker avatar image
38 ●1 ●0 ●5

OK, I figured this out.

I wasn't setting RespMsg.IndicationMaskFlag.RefreshComplete; on my response message,. I guess the adapter didn't relalise that the initial request had been fulfilled, so it closed and re-issued it.

Thanks for your help - Playing with the requestTimeout value alerted me as to what was going on.

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.

Upvotes
zoya faberov avatar image
23k ●22 ●9 ●14

Hello @RicknBaker,

There not supposed to be a limit to communication between consumer and provider, unless it's provisioned by the application designer, such as, for instance, our example applications from SDKs, many of them run for a short period of time, then exit gracefully.

If this behavior is not copied from example code, the the only way to find out why would be to take a look at the code.

You could attach the code here, and we will try to reproduce.

Or if you are a Thomson Reuters Developer Connect member, you could submit a TRDC request and it will be investigated by our TRDC developer support.

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.

Upvotes
RicknBaker avatar image
38 ●1 ●0 ●5

Hi Zoya. My application is loosely based around the ValueAdd example provider / consumer pair. If you turn on logging, you can see that they exhibit the exact same behavior that I've got: Every 45 seconds, the consumer issues a CloseMsg, followed immediately by a new RequestMsg which re-establishes the stream. I'd rather not send the close / request pair. How can I avoid this?

There are no timers in my code.

Thanks

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.

Upvotes
moragodkrit.chumsri_1 avatar image
7.6k ●15 ●6 ●9

@RicknBaker

Do you have full tracing log on consumer side? Just want to see all message consumer send and receive before it get the close message.

The time you mentioned, it may relate with parameter reqeustTimeout in RFA config. The default value is 45 sec. See RFA configuration section 3.1.1 RSSL Type Connection (RSSL Consumer).

The parameter may or 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 as suggestion by Zoya.


rfaconfig.png (10.4 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.

Click below to post an Idea Post Idea