Building a distributed app with PHP and Net_Gearman, part 3

In this installment, we’ll cover error handling in the client and we’ll add some useful callbacks to the worker script.

First, if you haven’t already, download the source for the examples in this tutorial

5. Client error handling

If your job class’s run() function fails to perform its work, you have two ways to handle it: you can return a value to the client’s complete callback that indicates a failure of some sort. Or you can throw a Net_Gearman_Job_Exception, which will trigger a call to the client’s fail callback if it is registered.

In our previous examples, we’ve been running the “date” command via our Example1 and Example2 job classes. Of course, this is contrived, but we’ll make it even more contrived so that our job class will only run the “date” command. An attempt to run any other command will throw a Net_Gearman_Job_Exception. Here is the relevant part of Example3.php:

Let’s register a fail callback in the client. Here is the relevant portion of gm_client5.php:

Run gm_worker5.php and gm_client5.php and you’ll get output like this:

There’s a lot of information here about the task. You’ll notice, though, that the text from the exception is not here. If you need access to that text, you might be better off returning it from the run() function instead of throwing the exception. Rather than using a fail callback, you would just handle the failures in your complete callback. It’s up to you.

6. Worker monitor callback

By default, a call to beginWork() is a bit of a black hole for your worker application.  You don’t really know what’s going on as the app waits for work, runs jobs, and waits again.  One solution is to define a monitor callback when we call beginWork().

The monitor callback gets called for a number of reasons:

  • before each job starts
  • after every job completes
  • once per minute while waiting for jobs

Let’s look at the changes we’ve made to gm_worker6.php:

The monitor function gets two parameters, a boolean indicating whether the worker is currently idle, and the time when the last job ran (a UNIX timestamp).  These values are set according to this table:

Time of Last Job
job start false not changed
job complete false set to current time
idle true not changed

When the worker starts up, the time of last job is set to the current time.

In order to see what’s going on, we’ll introduce a 2-second sleep before and after the command execution in our job class.  Here are the relevant lines from Example4.php:

If you run gm_worker6.php, then run gm_worker6.php twice and wait another 60 seconds, you will see output like this:

In this example, gm_worker6.php was launched at 20:12:40.  The first job was submitted at 20:12:43 and completed at 20:12:47.  The second job was submitted at 20:12:56 and completed at 20:13:00.  At 20:14:00, the monitor was called with $idle set to false.

You’ll notice that while we have a lot of good information about how the worker is functioning, the monitor can’t really tell the difference between job start and job complete.

In our next installment, we’ll talk about more options for tracking job status.

Part 1 · Part 2 · Part 4

Leave a comment

Your email address will not be published. Required fields are marked *