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 <[email protected]> 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 <[email protected]> > >> >> 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 >> >> >> >> >
-- List info: http://lists.roundcube.net/users/ BT/8f4f07cd
