>From more help by Hadrian and andrewm in IRC, I got it sorted out:
The missing piece is that I needed a way to let the consumer to be a
part of the routing, which is basically not what most of the canned
'Processors' let you do when JMS Queue's are involved, because pulling
a message off of the J
Hi Illtud,
Essentially I have no natural hierarchy. The issue is that these
workers will generally interoping with 3rd-party services, meaning
it's very hard to know upfront what their runtime characteristics will
be. We may find that one API of one 3rd-party fails alot and/or
takes a long tim
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
And then I find the Dead Letter Channel. It seems that perhaps, with
this mechanism, it might make sense to just reject the message once I
started a unit of work (or if I find the current worker that pulled
the task can't handle it), and let the routing re-route to the next
worker in line.
Not s
Hi all,
Let me describe my end-goal, and see what you all think:
I have this concept of a 'worker', which is on the consuming end of a
JMS queue. The idea is that I'd like to have many of these workers
deployed.
At the same time, there are different types of work to be done, and a
worker can do
