"all of my consumers are single threaded and thus I've never had this problem."
Me too. I was hoping to take advantage of multi-threading in a way that meant I was using the connection efficiently. "You can't delete a job that another client has reserved so using 2 clients won't work." That would confirm the results of my first dabble at this, which used two connections, though I could of swore I telnetted in from two different sessions and was able to do this. "Why not encapsulate the whole client into your thread (so - 1 client per thread)? Otherwise you have an obvious bottleneck built into your multithreaded system (as you are observing.)" The plan is to provide multiple connections but I'd like each thread to really take advantage of each connection. At the moment I have a single connection. As each job comes in I keep a track of it. If there are currently active jobs being processed, I switch to reserve-with-timeout, allowing the thread to process results. If there are no active jobs being processed, then the connection switches to traditional blocking reserve. The problem is that the blocking reserve obviously blocks the active thread. Mmmmm. I may have to sack off the blocking reserve and just go with reserve-with-timeout(0) and poll periodically. Not ideal, but I can't see a way around this at the moment. Thanks for your help Jerry and Chadkouse. -- You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/beanstalk-talk. For more options, visit https://groups.google.com/groups/opt_out.
