Hi Stefan, The point of Java having this setting on by default is very strong. Also, the point that both sides needs to be turned on in order for it to be effective makes a lot of sense, and also agrees with my observed test results.
I made the change in the code to turn this on by default based on your contribution. I made a few minor tweaks for .NET 1.1, but that's about it. Thanks for catching this and contributing the code patch! Let me know if I didn't merge in your changes correctly. They should be included in the 1.0.0 tag branch as well as in the trunk branch. Best, Jim On Fri, Aug 29, 2008 at 12:22 AM, Stefan_ <[EMAIL PROTECTED]> wrote: > > 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. > >
