[rabbitmq-discuss] suspending and resuming a QueueingConsumer

Jim Irrer irrer at umich.edu
Fri Jan 15 13:46:27 GMT 2010


Matthew -

Ok - I think I'll go with the channel close approach.  I was
really just checking to make sure that I was not stressing
the API in a bad way.

Thanks for your advice,

- Jim

Jim Irrer     irrer at umich.edu       (734) 647-4409
University of Michigan Hospital Radiation Oncology
519 W. William St.             Ann Arbor, MI 48103


On Fri, Jan 15, 2010 at 7:28 AM, Matthew Sackman <matthew at lshift.net> wrote:

> Hi Jim,
>
> On Thu, Jan 14, 2010 at 01:30:13PM -0500, Jim Irrer wrote:
> > Servers generally run in a loop, and in many cases spend most of
> > their time (very efficiently) waiting on read.  Given such a server,
> > we wish to suspend it before it processes another message.
> >
> > If there are several servers reading from the same queue, and
> > we want to suspend one of them, and if we used the ack-ing manually
> > approach, then one message would be held by the suspended server
> > and could not be processed by any of the others.  We would like that
> > message to instead be processed by one of the other servers.  I suppose
> > that the suspended server could write the message back to the queue,
> > but that seems a little like a hack.
>
> Ok, that makes sense. Is there a reason why you prefer suspending and
> resuming rather than just stopping/killing a consumer and starting a new
> one up?
>
> From your description, I'd have thought that closing the channel and
> maybe connection too, is the way to go.
>
> Matthew
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100115/13296d7a/attachment.htm 


More information about the rabbitmq-discuss mailing list