It is not possible to put an exact number on that as it depends. It would be limited by the tcp write buffer in the worst case scenario so will depend on the message size. Imagine, the broker is loaded so cannot read fast enough, the client writes as fast as it can till it blocks on a socket write, having filled the tcp buffers, the network dies. Potentially all of the messages in the tcp buffer are lost.
However the failover: transport trys to mitigate against this by tracking message sends in an LRU cache (use trackMessages=true as a query parameter). These messages are replayed on a reconnect, so in the case of a network failure, rather than a client being killed, it will be able to recovery with no message loss. On 14 September 2010 09:41, nervousbadger <nervousbad...@googlemail.com> wrote: > > We are using the "jms.useAsyncSend=true" option on the connection factory to > force persistent messages to be sent asynchronously. This means our client > does not wait for an acknowledgement from the server after sending a > message. Our clients are on a different host from the JMS server. > > Async sends are described here: http://activemq.apache.org/async-sends.html > > We are trying to figure out what the maximum number of messages that could > be lost would be if > > (a) either the JMS or the client host machine dies > (b) there is a network outage > (c) a software failure occurs that kills either the client or the JMS server > > We are not worried about filesystem corruption in this case. > > We don't know if it is possible to put a figure on this, that is what we > would like to find out. > > Thanks, > Pete. > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/ActiveMQ-sending-async-persistent-messages-what-is-the-maximum-that-can-be-lost-tp2537793p2538643.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > -- http://blog.garytully.com Open Source Integration http://fusesource.com
