No, pulling messages (aka prefetch size 0) is generally not bad idea. It can affect you performances but that depends on the loads you're having.
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 Mon, Jun 25, 2012 at 2:44 PM, Bruno Borges <bruno.bor...@gmail.com> wrote: > 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. >>
