OK, so if I take out the --ack flag it works fine, I don't get the redelivered messages, and I will probably just use that. However, for good measure I compared the qpid-stat results with ack on and ack off and I noticed that when acks were off, the source queue would have an equal value for msgIn and msgOut. However, when I enabled acks the msgIn value would keep increasing but the msgOut value would not change. The only difference I saw in the subscriptions list was the acknowledged column had a 'Y' when acks were on, the delivered valued would keep increasing in either case.
Thanks, -Brandon On Wed, Sep 21, 2011 at 12:20 AM, Gordon Sim <[email protected]> wrote: > On 09/20/2011 11:42 PM, Brandon Pedersen wrote: >> >> Is there any way to verify that it is indeed ack'ing those messages? > > You can use qpid-stat to check the properties of the subscription and > observe the messages on the queue being dequeued as consumed by downstream > broker. > >> >> On Tue, Sep 20, 2011 at 4:40 PM, Brandon Pedersen<[email protected]> >> wrote: >>> >>> Yeah, I used 1 for ack >>> >>> On Tue, Sep 20, 2011 at 4:19 PM, Ted Ross<[email protected]> wrote: >>>> >>>> Did you use a large number for the --ack argument in the route? Try >>>> using >>>> 1. >>>> >>>> It appears that the ack-batching is quite literal and the downstream >>>> broker >>>> *only* acks on modulo-N messages (i.e. it doesn't ack gratuitously after >>>> a >>>> period of inactivity). >>>> >>>> -Ted >>>> >>>> On 09/20/2011 05:22 PM, Brandon Pedersen wrote: >>>>> >>>>> Thank you! This almost works ;) I was worried about doing this because >>>>> I didn't want the local source queue to fill up because I wouldn't be >>>>> popping messages off it but it looks like it handles it properly and >>>>> removes them from the source queue when they have been pulled to the >>>>> destination exchange....awesome. >>>>> >>>>> However, I shutdown the destination broker, use spout to generate a >>>>> message, and then restart the destination broker. The message that was >>>>> missed while the broker was down is received but so is every past >>>>> message that was already received before the broker went down but with >>>>> redelivered set to true. I don't even know where these messages come >>>>> from because the queue on the source broker does not have any of those >>>>> messages. How can I get it to not receive the messages it has already >>>>> received? >>>>> >>>>> Thanks, >>>>> >>>>> -Brandon >>>>> >>>>> On Tue, Sep 20, 2011 at 2:37 PM, Ted Ross<[email protected]> wrote: >>>>>> >>>>>> Brandon, >>>>>> >>>>>> You can do this with a queue route (i.e. the downstream broker >>>>>> subscribes >>>>>> to >>>>>> an existing queue). >>>>>> >>>>>> Static exchange routes may be durable, meaning they will reappear >>>>>> after a >>>>>> restart, but their queues are always transient. Furthermore, when the >>>>>> route >>>>>> is down, there is no queue to hold the messages produced. >>>>>> >>>>>> If you create a queue, then establish a queue route to draw from that >>>>>> queue, >>>>>> the messages will accumulate there when the downstream broker is >>>>>> disconnected. >>>>>> >>>>>> When you set up the route in qpid-route, use the --ack N option with >>>>>> an N >>>>>> greater than zero. This causes the brokers to acknowledge messages >>>>>> and >>>>>> will >>>>>> ensure that in-doubt messages (i.e. in flight during the failure) will >>>>>> be >>>>>> re-transmitted upon reconnection. >>>>>> >>>>>> The qpid-route syntax is: >>>>>> >>>>>> qpid-route [OPTIONS] queue add<dest-broker> <src-broker> >>>>>> <exchange> >>>>>> <queue> [mechanism] >>>>>> >>>>>> where<exchange> is the name of the exchange on<dest-broker> >>>>>> where >>>>>> messages >>>>>> will be delivered to and<queue> is the name of the queue >>>>>> on<src-broker> >>>>>> where messages will be received from. >>>>>> >>>>>> -Ted >>>>>> >>>>>> On 09/20/2011 03:46 PM, Brandon Pedersen wrote: >>>>>>> >>>>>>> I am trying to get something like this working: >>>>>>> >>>>>>> - publish a message to a local exchange >>>>>>> - have the message get pushed to a remote exchange (or >>>>>>> pulled...preferably pushed) >>>>>>> and >>>>>>> - if the remote broker goes down, when it comes back up it will >>>>>>> receive all messages it missed while it was down >>>>>>> >>>>>>> I can get the first 2 working with a simple static route. However, >>>>>>> when the remote broker goes down it does not receive any of the >>>>>>> messages that were sent while it was down. Is there any way to do >>>>>>> this? And everything is being marked as durable (the queue, the >>>>>>> exchange, the binding, and the route) >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Brandon >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> Apache Qpid - AMQP Messaging Implementation >>>>>>> Project: http://qpid.apache.org >>>>>>> Use/Interact: mailto:[email protected] >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> Apache Qpid - AMQP Messaging Implementation >>>>>> Project: http://qpid.apache.org >>>>>> Use/Interact: mailto:[email protected] >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> Apache Qpid - AMQP Messaging Implementation >>>>> Project: http://qpid.apache.org >>>>> Use/Interact: mailto:[email protected] >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> Apache Qpid - AMQP Messaging Implementation >>>> Project: http://qpid.apache.org >>>> Use/Interact: mailto:[email protected] >>>> >>>> >>> >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:[email protected] >> > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
