On Sun, 2013-11-24 at 13:02 +0100, Andreas Veithen wrote:
> All,
>
> While debugging this scenario (on Ubuntu with the default receive
> buffer size of 8192 and a payload of 1M), I noticed something else.
> Very early in the test execution, there are TCP retransmissions from
> the client to Synapse. This is of course weird and should not happen.
> While trying to understand why that occurs, I noticed that the TCP
> window size advertised by Synapse to the client is initially 43690,
> and then drops gradually to 8192. The latter value is expected because
> it corresponds to the receive buffer size. The question is why the TCP
> window is initially 43690.
>
> It turns out that this is because httpcore-nio sets the receive buffer
> size only on the sockets for new incoming connections (in
> AbstractMultiworkerIOReactor#prepareSocket), but not on the server
> socket itself [1]. Since the initial TCP window size is advertised in
> the SYN/ACK packet before the connection is accepted (and httpcore-nio
> gets a chance to set the receive buffer size), it will be the default
> receive buffer size, not 8192.
>
> To fix this, I modified httpcore-nio as follows:
>
> Index:
> httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultListeningIOReactor.java
> ===================================================================
> ---
> httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultListeningIOReactor.java
> (revision 1544958)
> +++
> httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultListeningIOReactor.java
> (working copy)
> @@ -233,6 +233,9 @@
> try {
> final ServerSocket socket = serverChannel.socket();
> socket.setReuseAddress(this.config.isSoReuseAddress());
> + if (this.config.getRcvBufSize() > 0) {
> + socket.setReceiveBufferSize(this.config.getRcvBufSize());
> + }
> serverChannel.configureBlocking(false);
> socket.bind(address);
> } catch (final IOException ex) {
>
> This fixes the TCP window and retransmission problem, and it also
> appears to fix half of the overall issue: now transmitting the 1M
> request payload only takes a few 100 milliseconds instead of 20
> seconds. However, the issue still exists in the return path.
>
> Andreas
>
Andreas
I committed the patch to SVN trunk. Please review.
Could you please elaborate what do you mean by 'issue still exists in
the return path'. I am not sure I quite understand.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
