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