[rt-users] Unexpected session timeouts, RT 3.6.5

[Matt Pounsett]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Okay, so I've temporarily given up on trying to debug this.  I'm  
using the workaround of forcing RT back to using  
Apache::Session::File, which has appeared to work.

For posterity, here's everything I know about the problem along with  
some environmental information, in case someone somewhere down the  
road runs into the same thing and is interested in debugging it  
further than I did.

So...

Using RT 3.6.5 built from Ports on FreeBSD 6.2-RELEASE-p8, built to  
use FastCGI.  This is a single web server (no load balancing) with a  
single MySQL database on localhost.

The problem:  It appears that RT is randomly ignoring the session  
information returned to it by MySQL, and is initiating a new session,  
which forces the user back to the login screen.  The problem can be  
reproduced by clicking around the interface until you are  
unexpectedly presented with the login screen.

Watching HTTP headers:

Under normal behaviour, the web browser sends the session cookie to  
the web server and it responds with no new cookie, and whatever  
content was requested.  Periodically it unexpectedly responds with a  
new session cookie and the login page.

Watching MySQL query logs:

When RT unexpectedly presents the user with a login page, the query  
logs show that RT has done a lock, then select for the session ID, an  
unlock, as usual.. but then it inserts a new session row as if the  
query for the old session ID had failed.  Manually running this query  
at this time succeeds and returns the session data.

Watching RT error log:

Set to debug level, the RT error log shows nothing when this happens.

Watching web server error logs:

The web server error logs also show nothing out of the ordinary when  
this occurs.


I did some digging into the db-based session handling in order to  
drop in some overrides in ./rt3/local to add debugging output, but  
didn't get very far before trying the workaround mentioned at the  
beginning of this email.  Since that workaround is sufficient for my  
uses here, I'm sticking with it for now and abandoning further  
debugging.  However, if anyone (Jesse?) has some suggestions I'm  
happy to try them out and report back the results.

Matt


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFHRJ1AmFeRJ0tjIxERAqiQAJ4tDwIzGCEh1grFU06MtRHrxQj3dgCgi1/m
g570Gs2e1MjP7OW7dxkUhrs=
=Snks
-----END PGP SIGNATURE-----