I use Gearman entirely as a point to introduce asynchronous-ness in my application. There is a complicated and image-heavy PDF to generate and this happens on an automated schedule. To do this, I use the GearmanClient::doBackground method. This inserts a priority 1 job into my queue.
Using the doHighBackground() and the doLowBackground() methods insert jobs into the queue and checking out my persistent storage I see that the priorities work like this:
| priority | method | 0 | doHighBackground() |
1 | doBackground() |
2 | doLowBackground() |
|---|
Gearman works out which task is the next highest priority and will hand it to the next available worker – which means that I can set my automated reporting lower priority than the reports requested by real live people wanting them now, and everyone is happy!
SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
The worker is a Zend Framework application, run from the CLI, and it seemed like the Zend_Db_Adapter had no way of knowing when MySQL had let go of its end of the connection. I tried a few different things, including Zend_Db_Adapter::getConnection(), but without success – until I dug through the source code (with some help from a friend) and realised that ZF was not reconnecting at all if it thought it already had a connection. So instead, I expressly disconnected and reconnected the database handler. At bootstrap time, I place my database handle into the registry, so I simply added this at the start of the actual function that the gearman worker calls:
$db = Zend_Registry::get('db');
$db->getConnection();
At the end of my script, before it returns to the loop waiting for another gearman job, I just disconnect my database:
$db->closeConnection();
Now Zend_Db_Adapter knows that when I ask it to connect, it needs to go off and make a new connection, and everything works really well! I was seeing the errors because I’m still only testing the system so it can go days between getting any new jobs, and the timeout on MySQL is shorter than that.