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) -- You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To view this discussion on the web visit https://groups.google.com/d/msg/beanstalk-talk/-/ABDV5BojIaAJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en.
