Job reserve / timeout stats

[Yun Huang Yong]

In a thread[1] from Aug 2008 there's mention of a counter of the number
of times a job has been reserved. I can't find such a counter in the
current source and am wondering if we could add it.

The main scenario that I'm trying to address is where a client reserves
a job then drops its connection. The job is now in an unknown state
(depending on the application) and there is no indication to other
workers or a controller whether the job may have been run (perhaps
incompletely).

Currently the job is run through enqueue_reserved_jobs() which puts the
job back into 'ready' state without any indication that it had
previously been reserved.

Is it reasonable to either add a 'reserves' counter to the job struct,
or increment the 'timeouts' count?

I considered incrementing 'releases' but there is a meaningful
difference between a release instigated by the worker and a forced
release because of a connection drop (which is more akin to a timeout in
terms of indicating a possible error).

cheers,
yun

[1] http://preview.tinyurl.com/ppzjyk

--
Yun Huang Yong
y...@nomitor.com ...nom nom nom
+61 408 131 419
--

[Keith Rarick]

On Wed, Jun 3, 2009 at 8:56 AM, Yun Huang Yong <y...@nomitor.com> wrote:
> ...

> Is it reasonable to either add a 'reserves' counter to the job struct,
> or increment the 'timeouts' count?

I think this is reasonable. Instead or in addition, there could be
another counter just for this situation. I agree that there ought to
be a way to distinguish a job that has never been reserved from one
that has been dropped because the client crashed.

I just filed an issue for this.

http://github.com/kr/beanstalkd/issues/#issue/10

kr