Looking at tcpdumps it looks like the client side is timing itself out best I can tell, I clicked on compose, and then 5 minutes later it errored out:
T 2012/02/15 09:54:27.872598 64.251.160.49:7597 -> 64.251.189.36:80 [AP] GET /?_task=mail&_action=compose&_mbox=INBOX
T 2012/02/15 09:54:28.131830 64.251.160.49:7597 -> 64.251.189.36:80 [AP] GET /?_task=mail&_id=3521254364f3be344190ae&_action=compose
T 2012/02/15 09:59:31.208792 64.251.160.49:53863 -> 64.251.189.36:80 [AP] GET /?_task=mail&_err=session
Looking at the settings for that user in mysql I saw "keep_alive";i:300, I'm not sure how to interpret the preferences in that column or if that is even the issue. How might I go about making changes to that column manually? I don't see a keepalive setting in the preferences section in the gui, just in the config flatfile.
On Wed, Feb 15, 2012 at 9:08 AM, James Devine fxmulder@gmail.com wrote:
Any idea how I might verify what the problem is? I'm not seeing anything popping up in the error logs and I'm not able to reproduce this myself, I'm going off reports from customers
2012/2/14 Jernej Porenta jernej.porenta@arnes.si
On Feb 14, 2012, at 6:21 PM, James Devine wrote:
My fear is that the garbage collection from one or more webmail
machines is somehow stomping over active sessions
I don't think that is the actual issue if your cluster members have time in sync, since session functions use this SQLs (program/include/rcube_session.php):
- db_destroy (kill session; logout etc): DELETE FROM %s WHERE sess_id = ?
- db_gc (garbage collector): DELETE FROM %s WHERE changed < %s
Our problem is that cached information (cache_messages, etc) does not get purged automatically, but I don't know what is the deal about that.
LP, Jernej