<div dir="ltr">Is it meant to work like this or is it a matter of a feature not being implemented yet?<br><br>In my current implementation I am closing the channel occasionally, for no particular reason, but to get the redeliveries. This causes the processing to temporarily stop or slow down since I have to wait for all tasks to be done and acked before I can close the channel. (Since messages need to be acked on the same channel they were received on, as far as I know.)<br>
<br>It would probably be possible to have two parallel channels open, one active (receiving new tasks) and one waiting for its tasks to be done and acked, then closing the inactive one, making the previously active one passive and opening a new active channel. This would add the complexity of keeping track of what message that should be acked on what channel.<br>
<br>Are there any good patterns to handle this?<br><br>On Tue, Sep 30, 2008 at 12:01 AM, Matthias Radestock <<a href="mailto:matthias@lshift.net">matthias@lshift.net</a>> wrote:<br>> Ben Hood wrote:<br>>>><br>
>>> When are unacknowledged messages redelivered?<br>>><br>>> After the channel in which the initial receive has been closed and a<br>>> new channel has been setup.<br>><br>> To be precise, unacknowledged messages become eligible for redelivery when<br>
> the channel (or connection) on which they have been delivered is closed.<br>><br>> If a queue has more than one consumer, the message will be delivered to one<br>> of the remaining consumers. Otherwise it will be enqueued and can thus be<br>
> consumed by a consumer which comes along later.<br>><br>><br>> Matthias.<br>><br><br></div>