On Tue, Feb 28, 2012 at 11:09:43PM -0800, Farrel Lifson wrote: > > I have all the heavy lifting done in the participants themselves, with > (possibly) multiple Ruote worker daemons (possibly on different machines) > all communicating via a shared MongoDB storage acting as the 'queue'. My > initial experiments running on my laptop were successful but I'm worried I > might be a bit too optimistic as to whether this is the right way to go. > > I cant' see any obvious downsides and it cuts out another piece of software > to manage (RabbitMQ) but if I'm straying down the wrong path let met know!
Hello Farrel, it should be OK, that's how I'd do it too. If we look a bit further, placing a queue between ruote and some of the participants has an interesting advantage: not only ruote can queue work for those non-ruote workers. Ruote becomes just a[n orchestration] client among other clients that can place work orders. Of course if you don't need that level of refinement, then don't go for it (but remember that you can switch participant later when you have accumulated enough experience and metrics). Taking some time to look at RubyAMQP and co is worth it: http://rubyamqp.info/ Some of those patterns can be implemented with other queues than AMQP ones. I hope others will chime in, cheers, -- John Mettraux - http://lambda.io/processi -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
