Today RxNetty tries to alleviate the load of managing ByteBuf lifecycle from the user and employs an auto-release strategy, post invoking onNext on the subscriber listening for data.

The above is convenient in normal scenarios however it becomes non-intuitive in scenarios where the processing of ByteBuf happens in a separate thread as described in the issue #203

A slightly convoluted example of the above is in case of proxies where the request payload from the server is written as a request to the client (calling the origin server) and response from the origin (from HttpClient) is written to the server response. In this case, the thread change is subtle which is the eventloop processing the connection between the client and the server.

The above issues makes me feel that we should completely eliminate this auto-release behavior and follow a simple principle The eventual consumer of the ByteBuf should release the ByteBuf

Doesn't it mean that every client has to worry about ByteBuf management?

Yes, thats true. However, it isn't as bad as it sounds!

Few facts

• Whenever a ByteBuf is created, it has a ref count of 1. Everytime a ByteBuf is written to netty's channel, netty releases this ByteBuf. So, if the code is only shunting ByteBuf from one channel to another (proxy case), there is no special handling required.
• After RxNetty provides serialization support, the de-serializers and serializers will release the ByteBuf after use. So, majority of the code should not be dealing with ByteBuf
• For the users directly dealing with ByteBuf, the simple rule will be to unconditionally release it after they are done processing with the ByteBuf. There are no special cases of thinking about in which scenarios (same thread or different) one should release the ByteBuf and which they should not.

What about unconsumed ByteBuf s?

The above scenarios become a bit more complex when we have to deal with unconsumed ByteBufs. There are two distinct scenarios:

• RxNetty read a ByteBuf from netty but there was no subscriber. In this case the ByteBuf is unconsumed and RxNetty will release such a ByteBuf
• RxNetty passed a ByteBuf to a subscriber which cached the ByteBuf, which no code consumed. In this case, there should be an explicit dispose functionality available that should discard all unused ByteBuf. Much as this subject in zuul. In order to make this case easier for user, RxNetty will provide such a subject that can be used by users directly in scenarios where they need to cache.

Over all I feel, hiding the fact that netty expects users to do memory management of ByteBuf and making it easier for users, fills some gaps but exposes plenty more and adds confusion in the mind of users as to how to correctly use them. OTOH, if we are open about the fact that it is required to manage ByteBuf, it will create a much more intuitive system.