My fear is that the garbage collection from one or more webmail machines is somehow stomping over active sessions
On Tue, Feb 14, 2012 at 10:10 AM, Jernej Porenta jernej.porenta@arnes.siwrote:
On Feb 14, 2012, at 5:19 PM, James Devine wrote:
I have 3 machines running identical instances of roundcube setup in a
load balanced cluster sharing an instance of mysql. We seem to have issues at times where people's sessions expire in the middle of using roundcube. Is the best way to fix this to set the session_lifetime to 0 and do manual cleanup of sessions? --
List info: http://lists.roundcube.net/users/ BT/ef886a1a
Did you try using memcache for session data?
It might solve some issues, since it is way better performing than session data in MySQL and the paradigm is almost the same. I believe memcache session driver is available in 0.7 series, however you will still need MySQL for other caches, if you are using them.
Regards,
Jernej Porenta jernej.porenta@arnes.si ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia tel: +386 1 479 8800, fax: +386 1 479 88 99
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
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
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
On Feb 15, 2012, at 5:08 PM, James Devine 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
I believe that you should check the invalid session information in the roundcube log: Feb 15 18:38:49 a roundcube: Aborted session 1fkpva9li86orrd9lo0dlvlur3; no valid session data found Feb 15 18:40:19 a roundcube: Aborted session tv251jg03u5velh2t40om7tlg0; no valid session data found
But i don't know how to reproduce the issue. It might even be the customer browser issue...
Cheers, Jernej
It appears the session expiration issues were occurring when roundcube had problems talking to the imap server, either slow responsiveness or blatant error. Is there a way to prevent roundcube from closing the session when an imap error occurs, or at least increase the timeout value waiting for a response?
On Wed, Feb 15, 2012 at 10:48 AM, Jernej Porenta jernej.porenta@arnes.siwrote:
On Feb 15, 2012, at 5:08 PM, James Devine 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
I believe that you should check the invalid session information in the roundcube log: Feb 15 18:38:49 a roundcube: Aborted session 1fkpva9li86orrd9lo0dlvlur3; no valid session data found Feb 15 18:40:19 a roundcube: Aborted session tv251jg03u5velh2t40om7tlg0; no valid session data found
But i don't know how to reproduce the issue. It might even be the customer browser issue...
Cheers, Jernej
-
James Devine -
Jernej Porenta