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 future). Stefan -- View this message in context: http://www.nabble.com/Slow-performance-of-NMS-api-compared-to-Java-tp19158553p19214979.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
