First call channelReadComplete(...) before flush(...) for better performance
Motivation: In Http2ConnectionHandler we call flush(...) in channelReadComplete(...) to ensure we update the flow-controller and write stuff to the remote peer. We should better flip the order and so may be able to pick up more bytes. Modifications: Change order of calls. Result: Better performance
This commit is contained in:
parent
d63bb4811e
commit
d56f403c69
@ -484,9 +484,10 @@ public class Http2ConnectionHandler extends ByteToMessageDecoder implements Http
|
|||||||
// Trigger flush after read on the assumption that flush is cheap if there is nothing to write and that
|
// Trigger flush after read on the assumption that flush is cheap if there is nothing to write and that
|
||||||
// for flow-control the read may release window that causes data to be written that can now be flushed.
|
// for flow-control the read may release window that causes data to be written that can now be flushed.
|
||||||
try {
|
try {
|
||||||
flush(ctx);
|
// First call channelReadComplete(...) as this may produce more data that we want to flush
|
||||||
} finally {
|
|
||||||
super.channelReadComplete(ctx);
|
super.channelReadComplete(ctx);
|
||||||
|
} finally {
|
||||||
|
flush(ctx);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user