Future

These are disorganized thoughts about directions this project can take in the future.

As I become more familiar with Netty 4.1+, I can see a couple of architectural improvements already.

The first is to break this project into two ChannelHandlers instead of just one. The flow would go like this:

1. HttpDecoder or similar decodes bytes "coming in" into HTTP objects.
2. JerseyHttpDecoder decodes Netty metadata-oriented HTTP objects into ContainerRequests
3. JerseyMumbleMumble decodes Netty content-oriented HTTP objects somehow into additions to a CompositeByteBuf, just as happens today. (This step is suspect.)
4. JerseyContainerRequestHandler or something similar "eats" ContainerRequests (and maybe HttpContent objects so it can usurp the responsibilities of step 3 above) and then just writes as appropriate.

The end.

No need for coordinating writes via ChunkedWriteHandler. The OutputStream just writes using a ChannelHandlerContext directly.

The main insight I had behind this is that while you are not supposed to block the event loop on a read, you certainly can use ChannelHandlerContext from some other thread directly, because you can add a ChannelHandler to a ChannelPipeline with a thread group argument. If that's true, then you have to be able to do write operations directly from the ChannelHandlerContext, because a ChannelHandler never knows how it's been added. So there's no need to have ChunkedWriteHandler in the mix at all.

The challenge might be that a ContainerRequest has a ContainerResponseWriter associated with it that will already have a ChannelHandlerContext with it that is not the "right one". So at first Jersey write time, the handler in question will have to install the "right" ChannelHandlerContext for the writer to use.

Under extreme load, apparently a Channel can become writable and then unwritable. I don't know how this works in the sense that if the Channel "goes away" while you're in the middle of writing some content chunks and then "comes back" later…?