On 04/10/10 21:46, Seth Call wrote:
It seems to me the right thing to do is to have one queue per unit-of-work type. So if you are a worker and support 2 types of work, then you'd ultimately be listening to two queues. But, once you started working on one task pulled from one of the queues, it seems you'd want to dynamically stop listening to the other queue--and conversely, once the task is done, you'd start listening on that queue again. But right away I'm concerned how one could guarantee just one message is read from either queue at a time.
I think this could be done by using wildcards. If you have jobs of type A, B, C, D & E, and jobs A, B and C are processorder jobs (for example) and D & E are dispatchorder jobs, and you have 3 consumers, X, Y & Z. X can do processorders and dispatchorder -type jobs, Y can do processorders, and Z can do dispatchorder, then you can have queues: queue.processorder.A queue.processorder.B queue.processorder.C queue.dispatchorder.D queue.dispatchorder.E Then X could subscribe to queue.*, Y to queue.processorder.* and Z to queue.dispatchorder.* If your workers are single-threaded, and do their work in an onmessage (Java) method, then they'll automatically do the stuff you want (stop listening, not block other consumers) while they work on the message.
Another scenario is if no workers are currently available that can handle a particular type of task because they are all busy, but there are other things to do in the queue.
My solution would work for that, since there are separate queues. The only issue is if your task hierarchy doesn't break down handily like mine does (eg if Z could do A & E, but not the other tasks), but you'd have pretty odd workers to have that scenario (or I don't have much imagination). -- Illtud Daniel illtud.dan...@llgc.org.uk Prif Swyddog Technegol Chief Technical Officer Llyfrgell Genedlaethol Cymru National Library of Wales
