reserve counter does not increment in ones

[Ian Docherty]

We have had a problem in our production environment where the number of reserves for a job is hitting a limit (in our case 10) and the job is being buried.

However, it now appears that the first time we reserve the job, from our application, it already has a reserves value greater than 10.

We monitored tcp traffic with the following.

/usr/sbin/tcpdump -n -l lo -s 16436 -w /tmp/bt.dump port 11300

We see the following in the output.

INSERTED 1234

stats-job 1234

id: 1234

tube: my_queue

state: ready

pri: 10000

age: 0

delay: 0

ttr: 120

time-left: 0

reserves: 0

timeouts: 0

releases: 0

buries: 0

kicks: 0

RESERVED 1234 1051

stats-job 1234

id: 1234

tube: my_queue

state: reserved

pri: 10000

age: 10

delay: 1

ttr: 120

time-left: 119

reserves: 11

timeouts: 0

releases: 10

buries: 0

So, the question I have is, why is there a reserves of 11 by the time our application does the initial reserve call?

I would have expected that reserves is only incremented whenever our application makes the call to reserve?

Or are we miss-using this field?

Note. We are running beanstalkd-1.4.6-2.el5 (because that is the latest packaged version we can get)

[Ian Docherty]

Apologies to the list for the 'noise'.

The problem turned out to be another instance of the program running on a test environment, connecting to the production environment (yes I know, firewalls, I was just as surprised) which, if it reserved the jobs before the production machine could process them would cause the number of retries to be exceeded.

Sorry.