One other possible approach: * Make two tubes, S and T. * The observers listen on S, the consumer listens on T. * Put each job into S. * When an observer gets a job, it can copy the job to T and delete the original from S.
This lets exactly one observer see each job before it moves on to the consumer. If you give more details about your situation we might be able to offer more (or better) suggestions. kr On Thu, Apr 30, 2009 at 4:59 PM, Dan Mayer <[email protected]> wrote: > > Just some thoughts that might help... > > If you wanted you could just put the message onto multiple tubes > (queues)... Each listener would just pull it off their tube and delete > it. The consumer would do the same. Occasionally this is the simplest > way to broadcast over beanstalk. It puts more messages through the > system but if you aren't expecting it to be super high load this might > be fine. > > In our situation we found that having duplicate tubes for all the > listeners to work just fine. Then we just have a broadcast all method > that puts a message onto all the listening queues in the system. > > Off the top of my head that is the best way to do it with beanstalk, > but I would like to see what ever other thoughts people have on this. > > peace, > Dan > > On Thu, Apr 30, 2009 at 3:24 PM, DeRailed <[email protected]> wrote: >> >> Hi Erich, >> >> Thanks for the reply ! Please see annotations below. >> >> Best Regards... >> >> On Apr 30, 11:21 am, Erich <[email protected]> wrote: >>> Hi, >>> >>> A few questions about your situation: >>> >>> Does order matter amongst the observers? >>> >> No - Any order is fine as long as the get to see that job >> >>> Are all the observers potential consumers? >> >> No - All observers are just that. They will look at the job do their >> thing and push the job back on the queue >> >>> >>> How is the decision made about consuming (e.g. can there be 2 possible >>> consumers and how do you pick?) >> >> In my scenario, there would only be a single consumer at any time in >> the system. Only he can delete >> the job >> >>> >>> Can your situation be better handled by an MQ like RabbitMQ for the >>> broadcast and a job queue (beanstalkd) for the "only one consumer" >>> aspect? >>> >> >> I haven't look at RabbitMQ as of yet, was hoping this >> scenario could be handled with a single q ? Do you see any ways >> to make this work ? >> >>> Regards, >>> Erich >>> >>> On Apr 29, 3:58 pm, DeRailed <[email protected]> wrote: >>> >>> > Hi, >>> >>> > First of all thanks for this great project ! >>> >>> > I have a queue with a series of observers that just look at jobs as >>> > they come by and release then right >>> > away and a single consumer that will actually delete the job from >>> > the queue. >>> >>> > I would like to implement a strategy where all "observers" get a >>> > crack at looking at the job before it is >>> > actually consumed by the single consumer. Hence having the single >>> > consumer give all other workers a >>> > chance to look at the job before it actually consumes it. >>> >>> > Is this feasible with beanstalkd ? If so how ? I am currently using >>> > the ruby beanstalk-client to interface with >>> > the queue. >>> >>> > Thanks !! >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. 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 -~----------~----~----~----~------~----~------~--~---
