[ome-devel] session->closeOnDestroy() not closing session

[josh.moore at gmx.de]

Bernhard Holländer writes:
 > Hi Josh!
 > 
 > Thanks again for the detailed answer :-)

Very welcome.

 > >  > Maybe I do not understand the purpose of
 > >  > ServiceFactoryPrx::colseOnDestroy, but when I do the following:
 > >
 > > closeOnDestroy & detachOnDestroy are counterparts used to toggle a
 > > flag within your server-side OMERO session, but do not actually
 > > perform any actions. The default value for the flag is
 > > "closeOnDestroy" which means that if client.closeSession() or
 > > serviceFactoryPrx.destroy() is called, or the Glacier2 session times
 > > out (which ultimately calls serviceFactoryPrx.destroy()) then the
 > > OMERO session is also closed.
 > >
 > > This is the standard usage. If you need to share a session between
 > > multiple clients, or to keep it alive between client restarts, then it
 > > is necessary to call detachOnDestroy(), which initiates reference
 > > counting for the session. I need to add a self-contained example of
 > > this. If you (or anyone on the list) has a pressing need, please let
 > > me know.
 > 
 > Not needed at the moment. Just one question, is there a timeout for
 > the OMERO session like for the Glacier2 session?

Yes.

 > >
 > >  > try {
 > >  >     session_->ice_ping();
 > >
 > > ice_ping() will keep the Glacier2 session alive, but will not keep
 > > your OMERO session alive. For that, use sf.keepAlive()
 > 
 > Related to the question above: could it be that the OMERO session
 > times out before the Glacier2 session? If this is not the case, there
 > is no need for me to call keepAlive on the ServiceFactoryPrx since it
 > will be destroyed and recreated if the Glacier session timed out.

It's unlikely that the OMERO session will timeout before the Glacier2
session. The OMERO session defaults to 10 minutes, while the Glacier2
session defaults to 5 minutes. There's some question even amongst us
as to whether or not the difference makes sense, but I'll explain my
point-of-view, and look forward to anyone else's:

OMERO sessions are checked less frequently (>30 minutes) for timeouts
than the timeouts themselves (10 minutes by default, but
configurable). The Glacier2 is a C++ process that has nothing else to
do other than manage such sessions, so having it keep up with the ~5
minute pings and destroying sessions actively, rather than lazyily at
the 30 minute mark seems to me a healthy use of resources.

 > However, when implementing a ping thread as suggested in the
 > Ice-manual, would it not be sufficient to call sf->ice_ping()? Would
 > one need to call sf->keepAlive in the same thread every now and then?

One MUST call sf->keepAlive or some other OME-centric method to keep
the OMERO session alive. Further, calling it makes ice_ping
superfluous, since any method called on the serviceFactoryPrx will
equally keep the Glacier2 session alive. So when implementing a ping
thread, sf->keepAlive is probably your best choice.[1]

 > Thanks for your help! Bernhard

Cheers,
~Josh

[1] The arguments to keepAlive(ServiceInterfacePrx) and
keepAllAlive(ServiceInterfacePrx[]) can be null and still keep your
OMERO session alive. The intent, however, is that stateful service
instances should be passed in by your ping thread to keep them
individually alive. These service timeouts are currently disabled, but
may be re-activated as soon as 4.2. The logic being that a very large
service -- like the rendering engine -- may remain dormant for some
time before the entire session is closed.