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
nmetrowsky@digitalglobe.com mailto:nmetrowsky@digitalglobe.com
DigitalGlobe (r), An Imaging and Information Company