Hi Gordon, I did not specify a parameter to the sync call, which means it is default i.e. true. That means it blocks when called. If that is the case, why does it repeat the messages since I assume they have been acked since we forced a sync and waited a while before killing the broker. Also in our scenario, the broker ends up starting on another VM in our test setup.
On the receiver side, we acknowledge every message received. It is the unsettled count that seems to be the issue. If that count on the sender is 0, no messages are repeated. I can only get that if the link options on the sender are set to "unreliable". No other setup produces the result we want. Explicitly sinking the session does not seem to stop the repeated messages on a failover of the broker unless we have the link option as stated above. Nitin -----Original Message----- From: Gordon Sim [mailto:[email protected]] Sent: Tuesday, August 21, 2012 11:00 AM To: [email protected] Subject: Re: Can someone help to understand On 08/21/2012 03:27 PM, Nitin Shah wrote: > I tried the suggestion you had. I found that the scenario still exists > and messages are repeated when the broker killed and restarted. I > tried 2 things. I have a loop that sends 20 messages and then after I > have the session.sync() call. Are you specifying a parameter to that call? (If so is it true or false)? A blocking sync() should prevent you sending any more messages until the first 20 are confirmed which should reduce the number of resends by the sender to at most 20. > In this case the messages > that are repeated are the same as the setCapacity() call I had made > when the sender is created. If I perform the sync call every after > every send(), then the number of messages are reduced to 2 on a > restart of the broker. That's probably one resent by the sender and one resent by the broker. > Of course if I set the link option to be unreliable when I create a > sender, the messages do not get repeated. No, but then they may get lost. > I would like figure out why > this happens and maybe it is an education on my part. At present the supported guarantees are at-least-once or unreliable. The former may result in duplicates, the latter in message loss. In both cases the scope of the problem is the set of 'in doubt' messages for both sender and receiver. The number in doubt messages for the sender is limited by the capacity. You can also explicitly sync() the session. For the receiver, the number of in doubt messages depends also on the acknowledgement frequency. Does this help? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
