elecharny commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597513323
##########
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##########
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
- private static final boolean DEFAULT_TCP_NO_DELAY = false;
+ private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Not arguing here, I will revert but...
I do think that this flag should be opt-in, ie the Nagle algorithm should be
disabled by default. The use cases were it's useful are not really the most
frequent, and the drawbacks are numerous. If the default sendBuffer size is
set to 64Ko, then you have a delayed for every packet that has a lower number
of bytes to transfert. if you set the sendBuffer size to a lower value, then
you are sending way more packet than needed. In any case, if you are to send
some data that span on more than one packet, and the last packet is not
completed, then you'll pay a 200ms delay every time. Not very cool.
With Gigabits connections, sending a lot of packets is not really an issue
anymore, except on heavily loaded applications that aren't interactive (HTTP
may enter into this category, but with REST application, I would argue that an
immediate sending is a plus).
Regarding LDAP, requests are small there is no interest in differing the
packet sendings, so yes, I'm likely to deactivate the Nagle Algorithm.
Seems like on Linux they have added the TCP_CORK parameter to let the sender
decide when to send the data, bypassing the Nagle's algorithm completely, and
also solving the context switching pb at the same time (somehow it's a way to
say "you're responsability, not teh OS one", and I tend to agree). Sadly, this
is not portable, so currently it's not an option.
Last, not least, for TLS HS, Nagle's Algorithm is delaying the whole
negociation, which is a real PITA...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]