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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: http://hiramchirino.com > > Open Source SOA > http://open.iona.com >
