lroloson wrote:
I have added some reconnect logic to the example listener that I am running
on windows, and now when the connection is broken the listener reconnects
and I can continue receiving messages. At this point I have not detected any
missing messages. I have received one duplicate message, but I believe that
is to be expected when I break the ethernet connection in the middle of
transmission.
Yes, delivered but unacknowledged messages will be requeued and then
redelivered to subscribers.
I also noticed that all the messages are delivered, however some are
delivered out of order. I have been testing with serialized messages, when
the connection remains constant - i get messages 1-10 in order. But, if the
connection is broken (lets say at message 3) - when I restore the connection
some time later - I do not get 4, I get a message that was created later
(say 8 for example). The message delivery order becomes scrambled - lets say
1,2,3,8,9,4,5,6,7,10. Is there a way to get the messages to be delivered in
order?
You are using the 0.5 client and broker, right? I suspect this is due to
the fact that the broker does not immediately detected the broken client
connection and so does not requeue the messages it had sent before the
client has reconnected.
Do you get the same behaviour if the listener is on linux?
On the trunk now the broker has similar heartbeat checks to the client
and will abort the connection if two are missed; that may also help.
If you can enable more logging for the broker (e.g. --log-enable trace+)
that would probably shed some more light on the issue.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscr...@qpid.apache.org
