activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan_ <>
Subject Re: Slow performance of NMS api compared to Java
Date Fri, 29 Aug 2008 07:22:35 GMT

Hi Jim,

semog wrote:
> First, I would like to keep the default TcpNoDelayEnabled setting as
> false, rather than changing it to true.  Without knowing how it will
> impact other users, I think this is safer, and for those who want to tune
> their connection, they can do so.  If you can clarify how changing the
> default will help everyone in the general case, then we can change the
> default setting.  I just don't know what the full ramifications might be.

I understand that changing a default fault is not always appropiate, but the
java API also uses the TcpNoDelayEnabled setting with true default value and
I think that the user of the API might not understand why there are
different default settings. BTW the NoDelay-Flag is a socket option from the
underlying os so setting this through java or .NET should make no difference
and hence should have no other impact as it has for the java implementation.

> Second, there are two sides to the communication -- the client socket and
> the broker socket.  The WireFormatInfo sets the broker's socket settings,
> and your changes wait for the renegotiateWireFormat to come back from the
> broker in order to set the TcpNoDelayEnabled setting on the client's
> socket.  This 

I understand that the NoDelay Flag is set either on both or on neither. For
this reason the received WireFormat from the broker is compared to the
client default setting and only if both parties enable the flag and are
capable will the option be activated on the connection. AFAIK there is no
point in enabling this option on one client if the other client is not
capable or willing.

> will only work for OpenWire format, and not for STOMP.  Because of this,
> and other reasons, we need to have two separate setting flags.  I suggest
> the flag for setting the client's socket setting to be 
> "transport.TcpNoDelayEnabled".  As you already know, the existing broker's
> setting is "wireformat.TcpNoDelayEnabled".  Since this is wireformat
> specific, it is better to have a separate setting that can directly
> control the client's socket settings.

AFAIK the java implementation doesn't use the NoDelay-Flag for the stomp
protocol (at least I haven't found one). In my understanding it would only
be useful if both sockets support this option, so it seems not yet necessary
to make this option available for the STOMP protocol (perhaps in the

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

View raw message