TROEventReceiver stopping receiving

Remoting SDK
1

What might be the reason for events to stop being received? I’m using a TROEventReceiver and activating a long job on the server (maybe as long as an hour!) and I’ve found if it is too long, the client stops receiving the messages so it never knows the job gets completed.

I’ve built a variation of the chat demo that does this, and the server carries on sending the messages but the client stop receiving the message after 30 mins. Using a TROSynapseSuperTCPChannel.

(I’m using the latest release, on Delphi btw)

2

Hi,

Can you create a simple testcase that reproduces this case, pls?

  • What SessionManager/EventRepository components are used?
  • What value of SessionManager.SessionDuration ?
  • Will the issue be reproduced if you replace TROSynapseSuperTCPChannel with TROIndySuperTCPChannel?
  • Are you using SSL?

what case is it?

  • it stops to receiving events after 30 min inactivity
  • it received event on 29 min and never on 30 min
3

I’m using TROInMemorySessionManager, TROInMemoryEventRepository and I’ve not tried the indy channel, but that’s an interesting question of the session duration.

I think it is the session duration. I think I thought that because the events were being sent to the client that the session wouldn’t timeout but perhaps it does, and I need to send regular keep alive calls to the server (I have these built in for when the client sits quietly doing nothing anyway).

I’ll investgate that, and if can’t resolve it I’ll send you the test case I’ve built.

4

SuperTCPChannelChat_Server.zip (70.5 KB)
Here is a test case. I think it is related to the session duration. I set it (and the check interval) to 5 on the session manager, and it stops after 10 mins. Previously, when it was set to 15 mins, it stopped after 30 mins.

If you run the server, and open a client, after it logs in, click the ‘go regular’ button and the server will send regular messages for a while (based on the two spin editor values). After a period of time, they stop receiving the messages. 10 mins currently, as I say.

5

Hi,

this is SessionDuration:

Untitled
Untitled1544×960 334 KB

by default, it checks every SessionDuration min:

fTimer := TROThreadTimer.Create(DoTimerTick, fSessionCheckInterval * 60000);

We can update this timer and fire DoTimerTick every minute so it will expire sessions after SessionDuration + 1 minute

6

Thanks, I’ve just come to the same conclusion. I’ve fixed it by creating a timer that sends a regular keep alive message to the server whilst it waits for the conclusion of the long server process (60 mins in the sample there^) and it now sends those regular messages back to the client.

As I said, I thought that the session wouldn’t time out as there are regular updates going to the client but obviously that’s not the case.

7

Hi,

you can send events to inactive clients.
It isn’t a reason to update Session.LastAccessed …

8

Understood. Thanks for your help.
I was thinking it would be a reason to keep the session alive, but having thought it through I agree.

9

Hi,

you can manually set Session.LastAccessed to Now every time when event was sent.

Note: in this case server-side will think that session is alive even if client was disconnected for ages.

1 Like
10

I didn’t realise it could be that simple, but I prefer the option of the client pinging the server to say it’s still alive - plus I’ve picked up what you showed above (CheckSessionIsExpired), so that if the client has gone for any reason, the server can stop doing the work as it’s a very intensive process.