activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Gomes" <>
Subject Re: Async Message Defaults
Date Tue, 08 Jan 2008 00:03:21 GMT
Thanks, Hiram.  That was very helpful.  It gives me some insight on what to
expect.  I'll go back and play with this some more.  There may still be a
bug somewhere, because of the large discrepancy in the throughput of
OpenWire vs. STOMP wire formats.  Before I turned on the AsyncSend to true,
it would take OpenWire 6 minutes to send/receive 1000 messages (these are
small text messages with a single line payload), but it would take STOMP
approximately 30 seconds to do the same thing.  Once I turned on AsyncSend
to true, then OpenWire went to sub-second times and STOMP went to 2 to 3
second times.

- Jim

On Jan 7, 2008 12:56 PM, Hiram Chirino <> wrote:

> I'll have to review that the async send property in the .NET stuff is
> exactly the same as the java stuff but the idea is this:
>  - Async sends are faster since you don't have to wait for a 'broker
> ack/receipt' that confirms that the broker has received the message
> and it will not be lost.
> - Async sends are subject to message loss since depending on the size
> of the message and size of the OS TCP buffers you might have several
> messages 'sent' from the client perspective that still have not
> reached the broker.  If network or client/broker failure occurs those
> in flight messages are lost.
> Now Async sends are match up perfectly when sending non-persistent
> messages since the QoS on a non-persistent message basically says
> "yeah, you can drop me if shit happens".  And in the java case we
> async send non-persisent messages even if AsyncSend=false.  But if the
> message is persistent, it basically says the sending app wants a
> guarantee that when the send() method returns the message will not be
> dropped.  And we do the send sync with persistent message by default.
> Now in the java case if you AsyncSend=true, then even if the message
> is persistent then force the async send.  This produces more complex
> QoS that basically says you can drop me due to transport failure but
> if the message arrives on the broker then the broker will never drop
> me even due to broker failure.
> On a side note, in the Java case we also send persistent messages
> async if they are being sent in a JMS transaction and only send the
> final commit command sync.  This works since all commands before the
> commit command are processed by the broker before the commit.  And if
> any send failed as part of that commit then the commit fails.
> Hope that helped...
> Regards,
> Hiram
> On Jan 7, 2008 3:41 PM, Jim Gomes <> wrote:
> > Hello All,
> >
> > I have a question regarding the default settings of the .NET ActiveMQ
> > client.  By default, the AsyncSend for the connection is set to false.
>  I
> > would like to change the default to be true, but I would like to know
> the
> > rationale as to why it is currently set to false.  To me, the speed
> increase
> > is tremendous.  My testing shows that sending/receiving 1000 messages
> over
> > the network with AsyncSend set to false takes almost 6 minutes.  If I
> set
> > AsyncSend to true, it takes half a second to do the same thing.  To me,
> I
> > think the default should lean towards speed.  My tests also indicate
> that it
> > is just as reliable as having AsyncSend set to false.
> >
> > So, for anyone who might know: is there a reason why the default is set
> to
> > be false, and what are the downsides to changing the default to true?
> >
> > Thanks,
> > Jim
> >
> --
> Regards,
> Hiram
> Blog:
> Open Source SOA

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message