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:

(server name removed for security)

</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:

</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

Find more posts tagged with

trep

rfa

elektron

message

refinitiv-realtime

Accepted answers

RicknBaker

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.

All comments

zoya faberov

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.

RicknBaker

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

moragodkrit.chumsri_1

@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.

RicknBaker

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.

EXPLORE OUR SITES