On Thu, Jun 17, 2010 at 7:41 AM, Christian-Rolf Grün <[email protected]> wrote: > I am currently evaluating beanstalkd as a message queue solution for > an application.
Awesome! As others have noted many times before, you should stay open to the possibility of auxiliary storage for mutable job state, such as completion status. A SQL database or key-value store can do well here. For beanstalkd-only solutions... > I'd like to know if there are any built-in facilities > for the worker to send back data to the job producer after a job is > done. Not yet, but see http://github.com/kr/beanstalkd/issues/issue/3 > Failing that, can the worker modify the data associated with a job? > Can the producer alter the data of a buried job before kicking it? No. Jobs are immutable. > The last resort for sending data back would be the creation of reply > tubes for each job. How expensive is it to create a tube? That is a great strategy if you change it just a bit: create one reply tube for each producer, rather than for each job. It is cheap to create a tube, but performance with large numbers of tubes (thousands or more) has not yet been optimized. The "mailbox" tubes discussed in http://github.com/kr/beanstalkd/issues/issue/3 might make it easier to manage reply jobs in this strategy, depending on how you want to organize things, but they aren't strictly necessary. kr -- 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.
