Home Help Center

Session lost after TimeoutException

apetrovapetrov Member Andrey PetrovOrganization: FermilabProject: Accelerator Controls Middleware
Hi,

It's probably related to my previous post on recovery after a router failure.

My new situation: A Java client talks to Glacier2 router. On some request the router fails to reply quickly enough, and the client gets Ice.TimeoutException. It looks like after that all requests from that client receive Ice.ConnectionLostException.

In the server log I see:
[ 04/17/09 16:19:26.695 glacier2router: Glacier2: rejecting request. no session is associated with the connection. 
identity: XXXX ]

Both the client and the server also produce a number of messages on closing and reopening TCP connection.

Any suggestions how to recover after this timeout without recreating the session?

Thanks a lot,

~ Andrey

Comments

  • slypeteslypete Member Pete SylvesterOrganization: Coconaut StudiosProject: iPhone/iPod Game ✭✭
    This looks awfully familiar to the QueryPerformanceCounter issue that I ran into:

    http://www.zeroc.com/forums/help-center/4231-acm-problem.html

    May I ask what hardware and platform you are running?

    Pete
  • matthewmatthew NL, CanadaMember Matthew NewhookOrganization: ZeroC, Inc.Project: Internet Communications Engine ✭✭✭
    This sounds expected to me. If you get a timeout, the connection is closed, and thus the session is destroyed. Once the session has been destroyed, it must be re-established. Is it unexpected to get this timeout? What do you have your timeouts set to?
  • apetrovapetrov Member Andrey PetrovOrganization: FermilabProject: Accelerator Controls Middleware
    Pete:

    I have Linux on both sides. The client is Java.

    Matthew:

    Yes, your explanation makes sense. The only (?) way to recover after a timeout is to establish a new connection. Which means creating a new session on the router.

    What I'm doing is inventing various scenarios of troubles and ways of recovery from them. One possible problem is when a servant behind the router fails to reply in some relatively short time (which is not unreasonable, because the servants interact with a complex data backend). I can catch the timeout either in the router or in the client. Now I see that the right place to set the connection timeout, perhaps, will be the router, because no session (or any other state) is associated with the connection between the router and the servant. And I can probably assume that the router by itself will not normally produce unreasonable delays to the clients.

    One suggestion (if I may) about Glacier2... The connection between a client and a router is stateful, because it requires a valid session (unlike the simple case when a client talks directly to a servant, and no state is normally present). The current implementation of Glacier2, however, does not provide any means to recover that state and reuse the session once the connection is lost. I realize that if my application introduces its own application-specific state, it'll be solely responsible for keeping it in sync on the server and on the client. As the sessions are introduced in and required by the ICE infrastructure (without a session a client can't get data from a servant), it seemed to be reasonable to have some mechanisms implemented as a part of ICE that would recover sessions after various connection troubles.

    Thanks,

    ~ Andrey
  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    One suggestion (if I may) about Glacier2... The connection between a client and a router is stateful, because it requires a valid session (unlike the simple case when a client talks directly to a servant, and no state is normally present). The current implementation of Glacier2, however, does not provide any means to recover that state and reuse the session once the connection is lost. I realize that if my application introduces its own application-specific state, it'll be solely responsible for keeping it in sync on the server and on the client. As the sessions are introduced in and required by the ICE infrastructure (without a session a client can't get data from a servant), it seemed to be reasonable to have some mechanisms implemented as a part of ICE that would recover sessions after various connection troubles

    I think you could easy store session in the database you want in your SessionManager implementation, when a session is created you could query the database for the stored information and only initialize the session to defaults if there is not a previous stored session for this user, for made the persistence easy you could use a Freeze Map, a Freeze Evictor or implement code for retrieve the data for a Sql relational database, plain files or whatever you prefer to store the data.

    Also the client only need to have a proxy to the session in order to interact with the servants behind Glacier2, the session information is physically stored in the host where the session servant was created if you replicated this information in your client this is application specific, not something Ice architecture impose.

    If you want this data to be synchronized in your client you could send events from the session when the data you are interested in has changed that is likely to not be all the data the session stores.

    José
Sign In or Register to comment.