activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Borges <bruno.bor...@gmail.com>
Subject Re: ActiveMQ as a job/work broadcaster - Question regarding 'aborting' jobs
Date Mon, 25 Jun 2012 12:44:52 GMT
You can code a wise consumer that checks against the Topic message if its
name is in the list of consumers to be stopped.

Then all you have to do is publish a message with a List of consumers'
names.

*Bruno Borges*
(21) 7672-7099
*www.brunoborges.com*



On Fri, Jun 22, 2012 at 7:21 AM, Samuel Cox <crankydillo@gmail.com> wrote:

> 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 <dejan@nighttale.net>
> 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.
> > dejanb@fusesource.com | fusesource.com
> > skype: dejan.bosanac | twitter: @dejanb
> > blog: http://www.nighttale.net
> > ActiveMQ in Action: http://www.manning.com/snyder/
> >
> >
> > On Thu, Jun 21, 2012 at 8:44 PM, Samuel Cox <crankydillo@gmail.com>
> 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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message