The more jobs flowing through Gearman, the more likely something will happen. Queues can get backed up, workers can crash and performance can degrade. It is important to monitor the status of the Gearman ecosystem and be proactive about fixing problems. We can do this using the gearadmin tool.

Gearman comes with a few tools that make development and testing easier. The gearman program creates boilerplate clients and workers. The gearman program comes default with the gearmand package. Do not confuse gearman with gearmand. The gearmand daemon is what manages the queue, clients and workers. The gearman program is a tool to quickly create simple clients and workers. The options for gearman can be slightly confusing, so I will go through a set of examples on how to use them.

The Gearman examples on php.net are a great primer for groking how the Gearman client and worker interact with each other. One gripe I have is that the examples declare global functions for the worker to register. I feel this leads develpers down the wrong path. With PHP5.3, there is an easier solution though: anonymous functions.

The Gearman project has been slowly migrating from C to C++. This migration has gone under the radar due to the popularity of Cent OS 5 and given gearmand version of 0.14. This version of gearmand worked with any version of pecl/gearman and there was never any compelling reason to upgrade gearmand. That changed with the release of pecl/gearman 1.0

Writing the scaffolding for gearman workers is a pretty trivial task using the pecl/gearman extension. Keeping that scaffolding consistent between all the gearman workers in your application can get tough. I created a script that will remove the boilerplate gearman code and allow gearman worker scrips to simply be function definitions.

Gearman is one of my favorite technologies to use. So much in fact that I recently decided to take over the maintenance of pecl/gearman. While asynchronous tasks are a great feature, I find the ability to run multiple tasks in parallel to be much more useful. One of the biggest shortcomings of this approach was that uncaught worker exceptions would be treated as a successful completion of a job. I used to wrap all my workers in a generic try/catch block to prevent this from happening.  With the latest commits to pecl/gearman, I can now use the exception callback to properly track the exceptions.

The gearman job queue is great for farming out work.  After reading a great post about Poison Jobs, I limited the number of attempts the gearman daemon will retry a job.  This seemed fairly straight-forward to me: if a job fails, then the gearman daemon will retry the job the specified number of times.  I learned the hard way that it was not that simple.  There is specific criteria the gearman daemon follows in order to retry a job.