Periodically my application (a faceless daemon, so there's no
human-interface considerations) gets the following exception:
Mysql::Error: MySQL server has gone away: SELECT * FROM `messages` WHERE
(`messages`.`disposition` IS NULL) ORDER BY senttime
(ActiveRecord::StatementInvalid)
I've concluded this is an inevitable vicissitude of our MySQL server
setup. I'm now catching the exception. My question is what I should do
once I catch it.
I am sleeping for 5 minutes and retrying the find(). Is this enough?
Or should I re-run ActiveRecord::Base.establish_connection as well?
It's a naive question, but I'm naive about databases.
Periodically my application (a faceless daemon, so there's no
human-interface considerations) gets the following exception:
Mysql::Error: MySQL server has gone away: SELECT * FROM `messages` WHERE
(`messages`.`disposition` IS NULL) ORDER BY senttime
(ActiveRecord::StatementInvalid)
I've concluded this is an inevitable vicissitude of our MySQL server
setup. I'm now catching the exception. My question is what I should do
once I catch it.
I am sleeping for 5 minutes and retrying the find(). Is this enough?
Or should I re-run ActiveRecord::Base.establish_connection as well?
Is this in response to a normal controller request?
You might like to call Message.verify_active_connections!
before your find.
The application is not full Rails; it has no ActiveController instances.
That'll mean you'll miss out on Rails automatic connection verification.
You might like to call Message.verify_active_connections!
before your find.
An interesting proposition. verify_active_connections! has no rdoc available, and in fact abstract/connection_specification.rb marks it :nodoc:. Doesn't this suggest it isn't for typical use?
True. But your situation is not typical.
I don't exactly see what the method does when a connection is lost. Its last construct is a Hash#each_value, which doesn't suggest a useful return value. Does it raise an exception? Which? And what am I to do with it once I rescue it?
You just call it (ignoring any return value) before your find
to ensure the model's DB connection is established.
Also, while I'm on Rails 1.2.6, I see that the method is deprecated for 2.2.1 (and still undocumented as of 2.1).
On later versions of AR you can instead do Message.connection.verify!
I got this issue in JRuby / tomcat / rails before using JNDI.
Basically the issue was prior to rails 2.2 there was no connection
pool so if the timeout value in mysql hit a stale connection I got
this. So we implemented DBCP connection pooling in tomcat which
forced a test on the connection before using it.
Now with rails and connection pooling its probably worth looking to
see if the new code supports something like this.
I will say that the "gone away..." errors are gone but i still see a
lot of "broken pipe" errors which I am trying to resolve.