Archived
This forum has been archived. Please start a new discussion on GitHub.
Glacier2 Session Timeout
Hi Folks,
I want to ask about the strategy used by Glacier2 to decide whether the session is timed out. My observation is that if client creates session and then getting only callback invocations from server, Glacier2 destroys the session after period specified by SessionTimeout parameter. It leads me to the conclusion that callbacks does not considered by Glacier2 as "activity".
I would appreciate if somebody could comment whether my conclusion is correct. If it is correct, then I also want to ask whether such behavior is right, i.e it might be better to consider callbacks as session activity also.
Thank you,
Andrey.
I want to ask about the strategy used by Glacier2 to decide whether the session is timed out. My observation is that if client creates session and then getting only callback invocations from server, Glacier2 destroys the session after period specified by SessionTimeout parameter. It leads me to the conclusion that callbacks does not considered by Glacier2 as "activity".
I would appreciate if somebody could comment whether my conclusion is correct. If it is correct, then I also want to ask whether such behavior is right, i.e it might be better to consider callbacks as session activity also.
Thank you,
Andrey.
0
Comments
-
Hi Andrey,
It's just simpler to only take into account the client activity for the session timeout and so far it worked well since I believe you're the first one to ask about it
Is there a specific reason why you'd prefer not to setup a thread in the client to regularly ping the Glacier2 router to prevent the session from timing out?
Cheers,
Benoit.0 -
Hi Benoit,It's just simpler to only take into account the client activity for the session timeout and so far it worked well since I believe you're the first one to ask about it
I see. This is how pragmatic programmers are thinking
Is there a specific reason why you'd prefer not to setup a thread in the client to regularly ping the Glacier2 router to prevent the session from timing out?
Well, there are no specific reasons except of a bit of work need to be done by me . I can definitely do it. I just think that from the conceptual point of view it is more clean and less surprising if router will do it. Also, if you decide to keep it as it is, I think it would be good to mention it in documentation. I was surprised to see broken connection despite rather active communication from server to client.
Thank you,
Andrey.0 -
Note that pinging the session at regular time intervals in the client is useful for two purposes. One is to ensure that the Glacier2 session doesn't timeout. The other one is to monitor the status of the Glacier2 session: if the ping fails, the session has for some reasons been destroyed (and the client can either notify the end-user or try to re-create it). Don't you need to monitor the status of the session anyway in your client?
I suppose that if Glacier2 was to check for server side activity as well as client side activity, your client could passively monitor the status of the session (i.e.: the client could assume that the session is dead if it didn't receive requests within the last N seconds or minutes rather than sending ping requests). This could end up being more complicated to implement however.
In any case, we'll consider your suggestion and look into clarifying the manual!
Cheers,
Benoit.0 -
Note that pinging the session at regular time intervals in the client is useful for two purposes. One is to ensure that the Glacier2 session doesn't timeout. The other one is to monitor the status of the Glacier2 session: if the ping fails, the session has for some reasons been destroyed (and the client can either notify the end-user or try to re-create it). Don't you need to monitor the status of the session anyway in your client?
I suppose that if Glacier2 was to check for server side activity as well as client side activity, your client could passively monitor the status of the session (i.e.: the client could assume that the session is dead if it didn't receive requests within the last N seconds or minutes rather than sending ping requests). This could end up being more complicated to implement however.
In my particular case, the client is collecting sensor information sent by server applications. Also, the client may or may not call the server depending on the evaluation of the sensor data. And as you mentioned, some of this data must arrive on regular basis (like for example video stream or position information). In such case, there is no need to ping the router to find out that session is dead. So in my case it would be better if this work would be done by router.In any case, we'll consider your suggestion and look into clarifying the manual!
That would be great!
Thank you very much for clarifications!
Andrey.0
