activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bwatrous <>
Subject Re: CPP client: high latency for large messages
Date Fri, 29 Jun 2007 14:48:02 GMT

Hi David,
   Thank you for the advice.  I didn't think the tcpNoDelay would have an
effect since I was looking at relatively large messages :)
   Simply changing the connection URL solved the immediate problem, send
latency dropped right down into the microseconds as expected.  So far I
haven't had to make the suggested changes to the broker.


davidmc wrote:
> Hi there bwatrous,
> Your average sent time for the problematic RUN 1 (40ms) indicates that
> your problem is most probably caused by the bad Nagle's algorithm /
> Delayed ACK timeout interaction. This timeout is 40ms in Linux and 200ms
> in Windows / other systems.
> In short, the solution is to enable TCP_NODELAY flag on all your sockets.
> -This is possible in the ActiveMQ CPP client since version 2.0.1. You
> should append tcpNoDelay=true to the connection URL.
> -On the broker's side, you should enable the TCP_NODELAY flag in the
> broker's sockets. For this, following the documentation, you should append
> 'wireFormat.tcpNoDelayEnabled=true' to your connector's URI.
> In fact, this doesn't work and it is silently ignored. I discovered that
> 'socket.tcpNoDelay=true' works if you append it to an ActiveMQ Java
> CLIENT's connection URI; but it still doesn't work for a BROKER's
> connector URI.
> So, the only solution is to go to the broker's source code
> (org.apache.activemq.transport.tcp.TcpTransport.initialiseSocket method)
> and add the following line of Java code:
> --->          sock.setTcpNoDelay(true);         <---
> at the end of the method, so that all broker's sockets are created with
> TCP_NODELAY=true by default.
> The parsing of options in a broker's activemq.xml connector URI is broken
> right now, and it sadly doesn't seem to be a priority that this is fixed
> for next releases.
> So, I wonder how many folks encounter this '40 ms' problem, and when they
> finally guess that the solution is the TCP_NODELAY flag (not so easy),
> they try it and think it was not the right solution because
> 'wireFormat.tcpNoDelayEnabled=true' or 'tcpNoDelay=true' or
> 'socket.tcpNoDelay=true' get all silently ignored (no error message, but
> no effect on the sockets). Probably lots of frustration and lost hours...
> :(
> Related messages and JIRA's:

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message