[ome-devel] how to set glacier2 sessiontimeout

[josh.moore at gmx.de]

Bernhard Voigt writes:
 > Hi Josh!

Morning, Bernhard,

 > > Did you redeploy the application after modifying
 > > etc/grid/templates.xml?

 > Ah, no. I should have known that this is required.

Awfully nice of you to say, but not quite true. This is why in Beta4
the deploy happens automatically on start up: it can be easy to forget
that extra step.

 > > That's definitely the right place to be
 > > editing it (congrats on tracking it down).

 > Thanks! I have to admit, I was a little bit worried how many
 > different config files and styles/techniques are involved.

My feeling is that configuration has gotten simpler since Beta3.2, but
it's still not easy enough. Any feedback on that would be invaluable!

 > Anyways, grep is a good friend of mine ;-) and looking into the
 > python cli.py was useful, too.

Hmmm....good to hear that you worked your way through, but if there's
any particular documentation you feel is missing, let us know that as
well.

 > But still, I didn't get which files in particular need to be
 > edited, when I for example want to change the MaxMessageSize. Is it
 > just the template.xml and the ice.config for the client?

MessageSizeMax needs to be changed for every component in
templates.xml, that's correct, and for the client. Where exactly
configuration for the client takes place is up to you and your users,
but it will definitely need to be edited to make larger messages work.

 > > What exactly are you running into that you want to change the
 > > Glacier2.SessionTimeout?
 > 
 > We have an interactive client that allows to access OMERO from a
 > command line. In this app, if the session died, I'd like to catch the
 > exception and recreate it. For testing I didn't like to wait 300s
 > everytime until this exception is thrown.

Understood. However, there is another level of timeouts server-side
that could possibly catch you. Those will always throw
omero.SessionException or its subclasses. See omero/ServerErrors.ice
for more info.
 
 > Also I did thought about setting the timeout to 0 to have endless
 > sessions. At the end, I might go for the recommendation from the ZeroC
 > people to ping a proxy object in a separate thread to avoid the
 > session to die due to idleness.

We would agree. Having a background thread ping the server to keep
your session alive is long-term the most stable and supportable
solution for everyone. For example, once you start having significant
server-side state, having a session die under you can hurt.

 > > You may want to handle this
 > > differently. OMERO implements session counting independently of the
 > > Glacier timeouts which allows multiple clients to attach to a single
 > > session. Let me know if this would be of interest.
 > 
 > This could be of interest, it might be necessary for us to share a
 > session between different threads. Would this be a scenario that fits
 > to what you have in mind?

Definitely. But since the omero.client object and sessions are
thread-safe, you can share them directly in a single process. If,
however, you want to share the session across processes, session
re-use is necessary. Quickly:

import omero
c = omero.client()
s = c.createSession()

 # Prevents ref=0 from destroying the session
s.detachOnDestroy()

# Remote check
uuid = s.getAdminService().getEventContext().sessionUuid 

# Local check
uuid = s.ice_getIdentity().name

#
# And in the other process
#

import omero
c = omero.client()
s = c.joinSession(uuid)

 > Thanks! Bernhard

No problem at all. Hope it helps.
~Josh