Archived

This forum has been archived. Please start a new discussion on GitHub.

Glacier2 Session Cleanup

Hi,

I'm trying to figure out how to manage Glacier2 sessions. If the acitivity pattern is such that there could be long periods of inactivity, it would seem like I don't want to set a timeout. However, I don't want to depend on the client calling destroySession() either.

It appears that Glacier2 does not clean up a session even after the connection drops. Is there a way to make Glacier2 clean up the session if the connection drops?

Thanks
Budyanto

Comments

  • dwayne
    dwayne St. John's, Newfoundland
    Normally you set the Glacier2.SessionTimeout and then have your client ping the session periodically at some interval less than the session timeout, which the client can access by calling getSessionTimeout() on the session. For example, the Glacier2/chat demo in the Ice distribution does this by creating a separate thread for the pings. You could also make use the IceUtil::Timer class to implement this instead of creating a thread yourself.
  • Dwayne,

    Thanks for the response. I would like to avoid having to send keepalives as well cuz that's a burden on the client. Especially if the client is just a subscriber for IceStorm messages.

    Is there a reason why Glacier2 keeps the session even after a disconnect? Is the session used in anyway?

    Thanks
    Budyanto
  • xdm
    xdm La Coruña, Spain
    Hi,

    You should remove the session your self, Glacier2 will invoke destroy operation when the session timeouts.

    If you look at demo/Glacier2/chat it implement destroy as follow
    void
    ChatSessionI::destroy(const Ice::Current& current)
    {
        Lock sync(*this);
        if(_callback)
        {
            ChatRoomPtr chatRoom = ChatRoom::instance();
            chatRoom->leave(_callback);
            _callback = 0;
            chatRoom->message(_userId + " has left the chat room.");
        }
        current.adapter->remove(current.id); //remove the current session
    }
    

    Note that Glacier2 not keeps the session, the session is host by your configured session manager, so is its responsibility to cleanup the session when is not longer needed.

    Hope this help,
    José
  • benoit
    benoit Rennes, France
    Hi,

    In Ice 3.4, Glacier2 will automatically destroy sessions if it fails to forward a request from a backend server to the client because the client connection is closed.

    So for passive clients such as IceStorm subscribers, it won't be necessary anymore to set a session timeout and keep alive the session: as long as the client receives regular callbacks from a backend server, its session will eventually be destroyed automatically if it becomes unreachable.

    Glacier2 doesn't destroy sessions when the connection is closed because Ice doesn't provide a callback for connection closure, the reasons why it doesn't provide such a callback are explained here.

    Cheers,
    Benoit.
  • Thanks for the responses.

    Maybe I'm still missing it. It seems there's no way to guarantee that the session is cleanedup without specifying a session timeout and implementing a session manager. This also means that a client has to send keepalives to make sure that its session does not timeout.

    Even in version 3.4, if a client unsubscribe from IceStorm but forgets to call destroySession(), the session would still be left around if there's no session timeout.

    Thanks
    Budyanto
  • benoit
    benoit Rennes, France
    I don't think you're missing something. Sessions won't be cleaned up from the Glacier2 router if there's no activity for that session after the connection was closed and if you don't configure a session timeout.

    Glacier2 doesn't rely on TCP/IP connection closure to cleanup the session automatically because it's not reliable. For example, if the connection is dropped because a network router got rebooted or because the client crashed, Glacier2 might not detect the connection closure in a timely manner. In this situation, the connection is in a half-open state.

    So with Glacier2 from Ice 3.3.1, the only reliable way to clean up sessions is to configure the session timeout and have the client send regular keep alive messages. With 3.4, another option will be to have regular activity from the server back-ends to the client (and if a call on the client fails, the session will be cleaned up).

    Is there a particular reason why you want to avoid having to send keep alive messages in the client?

    Cheers,
    Benoit.
  • I'd like to guard against clients that don't conform. I'd also like to have the clients do as few connection related things as possible.

    Budyanto
  • On a related note, I tried using the IceGrid's SessionManager. Set the timeout to 10 seconds.

    I see the session gets created in IceGrid but
    I don't see the session timing out even if there's no activity.

    So in icegrid's config file
    IceGrid.Registry.SessionManager.Endpoints=tcp -h 10.11.22.122 -p 4060
    IceGrid.Registry.SessionTimeout=10
    
    And in glacier2's config
    Glacier2.SessionManager=SampleIceGrid/SessionManager
    Glacier2.SessionTimeout=10
    

    Thanks
    Budyanto
  • benoit
    benoit Rennes, France
    To guard against clients that don't conform, you need to enable the session timeout and your clients need to keep alive the session. You can easily wrap the keep alive functionality in a small class if you develop multiple clients.

    I just tried establishing an IceGrid client session through Glacier2 using the IceGrid session manager and the session did time out correctly after I killed the client so I'm not sure why it doesn't work for you. Could you describe a little more your test or provide us a small test case that demonstrates the issue?

    Cheers,
    Benoit.
  • Actually it is working now.

    I think I might have done something wrong.

    It appears that IceGrid.Registry.SessionTimeout on the icegrid config file has no effect.

    The timeout specified by Glacier2.SessionTimeout on Glacier2's config is honored though.

    I suppose this is the expected behaviour?

    Thanks
    Budyanto
  • benoit
    benoit Rennes, France
    Hi,

    Yes, this is expected. The IceGrid session timeout applies only for sessions created with IceGrid directly not through Glacier.

    Cheers,
    Benoit.