|
Hi Everyone, Based upon what I have seen in the Request Tracker code, and
those who are more familiar with it can correct me if I am wrong, I think I may
have found at least one explanation why one would get the message “MySQL
server has gone away” series of messages when adding a ticket in Request
Tracker. Of course, one should make sure that their CPAN libraries are all up
to date and that they do not have unusually low timeout numbers in the MySQL
my.cnf file, as it is possible older software and an incorrectly configure
MYSQL server could contribute to the problem. I have done this as part of my research
into the problem Upon my research I determined that when someone starts a Request
Tracker session, the user is assigned a cookie identifier for the duration of
the session. The cookie is given to the web server by Request Tracker and MySQL
is informed that the user will be connecting to to MySQL with the cookie
identifier as the database handle to establish the connection. So, the web
server, Request Tracker and MySQL should all be in sync with the cookie
identifier for the session. What we discovered, if someone relocates a laptop to another
location of the building and they leave their laptop logged into Request
Tracker, but during the move the network connection drops and reestablishes
itself, the cookie identifier may get expired by the web browser (Microsoft
Explorer in this case). When the user use starts to use Request Tracker, after
the move, they notice nothing out of the ordinary because they are still logged
in. Matter of fact they seem to process normally (web pages get loaded for the
function they are doing) until they try to submit a ticket or make an update to
a ticket. Because the cookie identifier is expired, Request Tracker does not
check to see if the cookie is really expired and passes the user on to MySQL
which already dropped the session because the cookie was expired. Request Tracker
assumes that if you are logged in, then you have a valid cookie and a valid session.
However, it does not verify the cookie is valid because of the above assumption.
The end result, MySQL detects someone trying to write to the database on a nonexistent
connection; then end result “MySQL server has gone away” will be generated
(no cookie = no connection to MySQL). Again, while this is not a complete explanation to the
problem and I do not have detailed expertise in the internals of Request
Tracker, I believe what I described here makes logical sense. Also, an individual
who generated the problem relayed to me exactly what they did and it was
described in the previous paragraph. I hope you find this information useful. Take care! Nick PS For the developers of Request Tracker, it may be a good
idea to force Request Tracker to always check to see if the cookie is valid, if
not, then the software should force a logout or at least inform the user
to logout and login again. It will also be a good idea for them to clear the
web browser cache, before logging in. --------------------------------------------------------------------------------- Nick
Metrowsky Consulting
System Administrator 303-684-4785
Office 303-684-4100
Fax DigitalGlobe
®, An Imaging and Information Company --------------------------------------------------------------------------------- |
_______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
