activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samuel Cox <>
Subject Re: ActiveMQ as a job/work broadcaster - Question regarding 'aborting' jobs
Date Fri, 22 Jun 2012 10:21:37 GMT
We do use a topic to broadcast the abort to the workers (consumers),
but the abort targets a specific job (message).  However, I don't want
to stop all the consumers.

Is setting the prefetch size to 0 a bad idea?

On Fri, Jun 22, 2012 at 3:18 AM, Dejan Bosanac <> wrote:
> If I understood it correctly you want to be able to notify the worker
> (consumer) to stop executing the jobs (stop consuming). If that's the
> case, you can use an additional topic for events like this and your
> worker should subscribe to it as well. So when master sends a message
> to the topic, workers can disconnect (thus effectively nacking all
> prefetched messages).
> Regards
> --
> Dejan Bosanac
> Senior Software Engineer | FuseSource Corp.
> |
> skype: dejan.bosanac | twitter: @dejanb
> blog:
> ActiveMQ in Action:
> On Thu, Jun 21, 2012 at 8:44 PM, Samuel Cox <> wrote:
>> Hi,
>> We use ActiveMQ and Camel to facilitate distributing jobs (JMS
>> messages) from a master to multiple workers.  We have to support the
>> ability to reliably abort these running jobs.  Currently, when our
>> master gets an abort request, it simply broadcasts this out to the
>> workers.  We don't (currently) keep track of which worker has a job,
>> nor do we even check the job queue to see if the message representing
>> the job has been dequeued.  Once upon a time, we did have the workers
>> sort of spin on aborts until it actually got the job (assuming it
>> didn't already have it) and then abort, but I argued that there has to
>> be a better way.
>> So...I'm asking for help finding a better way.  We do have some ideas;
>> however, I figured others must have surely already solved this, so I'm
>> checking for more elegant solutions.  I'm currently leaning towards a
>> queuebrowser + track worker that has job + target specific worker with
>> abort request.  It still seems like this might be overkill.  I just
>> need to guarantee that work can get aborted...
>> If you have ideas or can point me to tutorial/samples/etc., it would
>> be appreciated.

View raw message