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 <crankydi...@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 <de...@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. > > dej...@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 <crankydi...@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. >
