[RCU] New Roundcube Deployment

David Carter dpc22 at cam.ac.uk
Sun Aug 11 19:23:29 CEST 2013

On Sun, 11 Aug 2013, Thomas Bruederli wrote:

> Hmm, sessions should not expire while somebody has an active window and 
> is still typing a message. This is the real issue that needs to be 
> investigated and resolved. But you already mentioned that the memcache 
> fix is applied in your deployment, right?

Yes. Further experimentation yesterday does suggest a difference in 
behaviour between the memcache and normal database code.

If I click Send and the session has expired using memcache session storage 
the browser just hangs with a spinning "Sending" icons, which is what I 
reported yesterday. The same experiment using database session storage 
appears to send the message successfully (which I don't quite understand 
if the session has expired: is there special handling?) and then bounce 
the user to the login page with a "session has expired" error. I think 
that this is what you are expecting to happen here.

A related curiosity in the client side Javascript:

It looks like that if you click Send without any network connection at all 
(I disabled wireless on my laptop a lot while testing the the KeepAlive 
stuff yesterday) then you end up with a stuck Sending spinner. Which is 
fine: the browser can't do much else at this point. However none of the 
buttons in the Roundcube user interface respond if you restore the network 
connection and try again, which is a little concerning.

If I force a page reload and the session hasn't timed out then Roundcube 
carries on its merry way, but you have lost the current draft message.

I haven't tried a variety of clients. The problem might be specific to 
Chrome running on my Linux workstations. This might be where the helper 
app that you mentioned would step into the rescue.

>> I imagine that is what is being reported here. While the KeepAlive stuff
>> seems to be working, I imagine that it is quite common for people to close
>> up their laptop and move to another room before continuing a message.
> Aha!

Looking at my logs, I'm pretty certain that this is what is going on, at 
least in the two cases reported to me so far: there is a longer gap 
between KeepAlives than I would expect.

This would have worked with our old Webmail application, so people haven't 
adapted their behaviour. My workaround was to increase session_lifetime to 
4 hours, to match the old Webmail's behaviour.

David Carter                             Email: David.Carter at ucs.cam.ac.uk
University Computing Service,            Phone: (01223) 334502
New Museums Site, Pembroke Street,       Fax:   (01223) 334679
Cambridge UK. CB2 3QH.

More information about the users mailing list