Action<ServerHttpExchange> httpAction = new Action<ServerHttpExchange>() {
@Override
public void on(ServerHttpExchange http) {
new Timer().schedule(new TimerTask() {
@Override
public void run() {
http.chunkAction(new Action<String>() {
@Override
public void on(String chunk) {
System.out.println("on chunk: " + chunk);
}
})
.read();
}
}, 10 * 1000);
}
};
With the above handler, if client sends a text chunk per every second, Netty and Vert.x lose 10 chunks that sent for 10 seconds and Servlet 3 at least Jetty 9 doesn't lose any chunk (Instead, the first chunk after read method contains those 10 chunks). I think such usage is not common but it would be worth discussing its different behavior about reading request.
In Netty, it seems that each request chunk corresponds to a message passed through a channel so that if handler does nothing with that message, it would be evaporated. Therefore, read method of NettyServerHttpExchange actually does nothing except setting charset encoding in case where the body is supposed to be text, and added chunkAction will be fired even though read method is not called.
In Jetty, it seems that each request chunk is accumulated into somewhere that accessed by req.getInputStream and it's evaporated once reading body is done or that request-response exchange's life cycle is done. This behavior matches well with the current goal of read method.
To make the behavior of read consistent across Netty and Jetty:
On the side of Netty, read method is not necessary so should be removed. That means when HTTP exchange is given, platform should start reading body (being ready to receive chunk in case of Netty). It's probably the performance penalty to Jetty and some optional configuration like charset encoding may be required to read body because we don't have ByteBuf concept.
On the side of Jetty, read method should assure no chunk is lost even though it is delayed. Netty should accumulate read chunks to somewhere if read hasn't been called and flush them on read call. It's probably the memory penalty to Netty. As read method may have to accept options, this way looks better.
With the above handler, if client sends a text chunk per every second, Netty and Vert.x lose 10 chunks that sent for 10 seconds and Servlet 3 at least Jetty 9 doesn't lose any chunk (Instead, the first chunk after read method contains those 10 chunks). I think such usage is not common but it would be worth discussing its different behavior about reading request.
In Netty, it seems that each request chunk corresponds to a message passed through a channel so that if handler does nothing with that message, it would be evaporated. Therefore,
readmethod ofNettyServerHttpExchangeactually does nothing except setting charset encoding in case where the body is supposed to be text, and addedchunkActionwill be fired even thoughreadmethod is not called.In Jetty, it seems that each request chunk is accumulated into somewhere that accessed by
req.getInputStreamand it's evaporated once reading body is done or that request-response exchange's life cycle is done. This behavior matches well with the current goal ofreadmethod.To make the behavior of
readconsistent across Netty and Jetty:ByteBufconcept.readhasn't been called and flush them onreadcall. It's probably the memory penalty to Netty. Asreadmethod may have to accept options, this way looks better.