[rabbitmq-discuss] adjusting timeout for non-acked messages to be requeued

vishnu pathsny at gmail.com
Wed Dec 30 03:37:53 GMT 2009


Hi Alexis
   thanks, I think Im getting a better understanding now. Initially I wanted
to look at auto requeueing for circumstances when my client subscribing to
events went down or got disconnected. Now my understanding is that in those
cases, messages get auto requeued.
    However, if I choose not to autoack, then it looks like the
responsibility of requeuing a client, forcing a time delay on the delivery
and also maybe forcing a limit on the number of passes through the queue is
going to have to become subscriber responsibility. I was hoping to handle
that as a configuration on the queue itself outside of code, but I guess
that isn't possible.

(the use case we have requires us to make sure that every message is
processed as far as possible. Meaning actual failures and successes are sent
onward, but failures for technical reasons require us to try again later, by
which time the technical issue might have been resolved).

Im taking a look now at the task management systems now.

Please do describe the other ways of forcing a requeue, I'd love to know
what my options are.

On Wed, Dec 30, 2009 at 4:34 AM, Alexis Richardson <
alexis.richardson at gmail.com> wrote:

> Vishnu
>
> I am not the best person to answer this question, but I can tell you
> that your behaviour can be achieved without requiring timers.
>
> Assuming you are unwilling to simply close the channel and force the
> requeue, then:
>
> 1. You could explicitly requeue by re-publishing the message.  No need
> to use acks here.
>
> 2. You could look at what one of the many task management systems do.
> For example celery or quebert.
>
> http://ask.github.com/celery/introduction.html
> http://bytebucket.org/adroll/quebert/
>
> Or look at the list here:
> http://delicious.com/alexisrichardson/rabbitmq+work
>
> 3. Other ways to force a requeue.  I am not going to try and describe
> these yet, in case I say something misleading.
>
> Let me know what you think.
>
> alexis
>
>
>
> On Tue, Dec 29, 2009 at 8:34 PM, vishnu <pathsny at gmail.com> wrote:
> > Adding back to the list, sorry stupid email client.
> >
> > would anyone know how this decision is made? When unacked messages get
> > requeued to be sent? I know it happens if the client disconnects, but
> does
> > it also happen on rollback?
> > Im trying to setup a system whereby if my subscriber picks up an item
> from
> > the queue and for some reason is unable to handle it, the item gets
> readded
> > to the queue
> >
> > On Tue, Dec 29, 2009 at 8:36 PM, Alexis Richardson
> > <alexis.richardson at gmail.com> wrote:
> >>
> >> Vishnu
> >>
> >> On Tue, Dec 29, 2009 at 2:57 PM, vishnu <pathsny at gmail.com> wrote:
> >> > hi, sorry Im a bit confused. But the behavior of moving the message
> from
> >> > the
> >> > unacknowledge queue to the ready queue is already a part of rabbitmq.
> >>
> >> In what way?
> >>
> >>
> >> > There
> >> > must be some magic constant somewhere which governs this musn't there?
> >>
> >> If there were then it need not be time-based.
> >>
> >> alexis
> >>
> >>
> >> > On Tue, Dec 29, 2009 at 7:18 PM, Alexis Richardson
> >> > <alexis.richardson at gmail.com> wrote:
> >> >>
> >> >> Vishnu
> >> >>
> >> >> On Tue, Dec 29, 2009 at 4:37 AM, vishnu <pathsny at gmail.com> wrote:
> >> >> > Hi
> >> >> >     I'm trying to use rabbitmq for an web application thats close
> to
> >> >> > synchronous. The main reason I'm looking at rabbitmq is for the
> >> >> > reliability
> >> >> > and transactionality. The idea is for the webapplication to pump
> >> >> > messages
> >> >> > into the queue and for a down stream application to subscribe in
> >> >> > acknowledgement mode and for each message start a transaction,
> >> >> > attempt
> >> >> > to
> >> >> > process the message and if it fails for technical reasons, to
> >> >> > rollback
> >> >> > the
> >> >> > transaction.
> >> >>
> >> >> OK.
> >> >>
> >> >>
> >> >> > However, I would like to be able to configure the time for
> non-acked
> >> >> > messages to get requeued to be picked up. Where can this be done?
> >> >>
> >> >> This and other 'time based' behaviours are frequently requested, but
> >> >> *alas* are not yet built-in to RabbitMQ.
> >> >>
> >> >> However, don't give up.  You could create a consumer (in any
> language)
> >> >> which managed this for you, eg enforcing a disconnect after some time
> >> >> has passed.  Or, if you are feeling brave you could create a plugin
> to
> >> >> do this 'inside the broker'.  Plugins have to be written in erlang.
> >> >>
> >> >> I hope that helps.  Perhaps the list will have more immediately
> useful
> >> >> suggestions.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> alexis
> >> >>
> >> >>
> >> >>
> >> >> > thanks
> >> >> > Vishnu
> >> >> > _______________________________________________
> >> >> > rabbitmq-discuss mailing list
> >> >> > rabbitmq-discuss at lists.rabbitmq.com
> >> >> >
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
> > _______________________________________________
> > 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/20091230/f0a4464a/attachment.htm 


More information about the rabbitmq-discuss mailing list