Tim, Alexis here from RabbitMQ.
This is definitely a good use case for RabbitMQ and AMQP. It has been implemented by quite a few folks, in a range of styles. In your case I think you probably want to express subscription interest based on single keywords (eg "bigjob", "littlejob"). You would do this by binding your work queues to a direct exchange by subscription key, and then attaching consumers to queues (which can be shared, or single- user). Consumers who wish to create work would simply publish messages to the exchange, attaching a suitable routing key to each message they send. So in this example keys are, in effect, job types. Here are some links you may find useful: * http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ - introductory article by a python user * http://www.rabbitmq.com/how.html - general linkfest * http://github.com/ezmobius/nanite/tree/master - one of several ruby based worker patterns Please do cross-post to rabbitmq-discuss if you want the RabbitMQ community to comment. Cheers, alexis On 23 Apr, 03:10, TylerWeir <tyler.w...@gmail.com> wrote: > You may want to talk to Steve Jenson (aka @stevej) about your app > needs. > > I'm not sure he still visits the list, so twitter may be the best > avenue. > > On Apr 22, 6:48 pm, Tim Perrett <timo...@getintheloop.eu> wrote: > > > Guys, > > > Im just starting to look at RabbitMQ and lift-amqp. I have a situation > > where by I have a central pot of information and a bunch of different > > consumers that want to keep up to date with changes to things they are > > interested in (specifically, we'll call the things they are interested > > in "jobs"). > > > Im thinking that the central application will probably use some kind > > of actor schedule to constantly update its information about all jobs > > (as it in turn will be getting it through some SOAP services), > > however, what I would then like it to do is notify any other consumers > > (which will be other applications) that have opted to subscribe to > > information / updates about that job via AMQP. Consumers will also be > > able to hand messages to the central service and effectively say "deal > > with this job and notify me about any changes". > > > Now then, excuse my complete ignorance as im new to AMQP but its > > possible to build such a workflow, right? Any pro's / con's in doing > > this? > > > Just looking for a bit of a sounding board right now so any > > information / feedback would be greatly appreciated > > > Cheers, Tim --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
