[
https://issues.apache.org/activemq/browse/AMQ-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38800
]
Helmut Janknecht commented on AMQ-1156:
---------------------------------------
On Linux 2.6.16 or 2.6.17 perhaps setting this {{sysctl net.ipv4.tcp_abc=0}}
may help as described in
https://issues.apache.org/activemq/browse/AMQ-1137#action_38799.
> option "wireFormat.tcpNoDelayEnabled=true" is ignored
> -----------------------------------------------------
>
> Key: AMQ-1156
> URL: https://issues.apache.org/activemq/browse/AMQ-1156
> Project: ActiveMQ
> Issue Type: Bug
> Components: Documentation, Test Cases, Transport
> Affects Versions: 4.0, 4.1.0, 4.2.0
> Environment: Any.
> Reporter: David MartÃn Clavo
>
> *A. Description*
> Setting the wireFormat.tcpNoDelayEnabled flag to true in connection uri's
> (for example _"tcp://localhost:61616?wireFormat.tcpNoDelayEnabled"_) has no
> effect:
> The sockets created in ActiveMQ do not have the TcpNoDelay flag set to true.
> You can verify this for example in the following way: insert the line
> _System.err.println(sock.getTcpNoDelay());_ at the end of the method
> _org.apache.activemq.transport.tcp.TcpTransport.initialiseSocket_.
> Also you can try my test at
> http://www.nabble.com/High-latency-for-small-messages-problem-t3159901.html
> which makes latency appear if Nagle's algorithm is not disabled.
> This affects versions 4.0, 4.1.0, and 4.2.0 latest snapshot. I guess 4.0.2 is
> affected too.
> *B. Reason*
> After looking at the source code to understand how the options are set, i saw
> that in the method
> org.apache.activemq.transport.tcp.TcpTransportFactory.compositeConfigure the
> following line appears:
> _Map socketOptions = IntrospectionSupport.extractProperties(options,
> "socket.")_;
> and also that the method to set the TcpNoDelay option in class
> _org.apache.activemq.transport.tcp.TcpTransport_ is called _setTcpNoDelay_
> and not _setTcpNoDelayEnabled_
> Therefore, I tried to write _"socket.tcpNoDelay=true"_ instead of
> _"wireFormat.tcpNoDelayEnabled=true"_ and it *worked!* This is a *workaround*.
> But, _"wireFormat.tcpNoDelayEnabled"_ option is not refused (as
> _"wireFormat.tcpNoDelayTypoEnabled"_ would be). The option
> _"tcpNoDelay=true"_ is not refused either, but DOES NOT work either.
> *C. Fix*
> So, please, for the sake of the poor soul who's next going to try to disable
> Nagle's algorithm without noticing any effect, and will start looking for the
> problem elsewhere (and for the sake of consistency also):
> -Either change the documentation
> (http://www.activemq.org/site/tcp-transport-reference.html and
> http://www.activemq.org/site/configuring-wire-formats.html) to say that one
> should use the _socket.tcpNoDelay_ option, or
> -Change the code to obey the documentation (and make it refuse old options
> like just _"tcpNoDelay"_ who have no effect).
> Personally I would change the documentation ASAP so that people know about
> the _"socket.tcpNoDelay=true"_ workaround until next version, and then change
> the code to recognize the _"wireFormat.tcpNoDelayTypoEnabled"_ option. I'd
> like to point out that the own ActiveMQ test cases use
> _"wireFormat.tcpNoDelayTypoEnabled"_ .
> *D. Related issues*
> This is related to a previous post of mine:
> http://www.nabble.com/High-latency-for-small-messages-problem-t3159901.html
> Doing quick synchronized sends showed a 39ms latency if the broker is running
> in Linux, and a 200ms latency if the broker is in Windows (by the way, if
> someone knows the bottom reason for this exact latency times, please tell
> me). Putting the _"wireFormat.tcpNoDelayTypoEnabled"_ to true in order to
> disable Nagle's algorithm had no effect (because ActiveMQ does not recognize
> it).
> Very probably this is also related to issues
> https://issues.apache.org/activemq/browse/AMQ-1143 and
> https://issues.apache.org/activemq/browse/AMQ-1137 (in this one probably
> Helmutt tried to set the wireFormat.tcpNoDelayTypoEnabled without success
> because of this).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
