Remove ByteBuf auto-release #264
Description
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
ByteBufis created, it has a ref count of 1. Everytime aByteBufis written to netty's channel, netty releases thisByteBuf. So, if the code is only shuntingByteBuffrom 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
ByteBufafter use. So, majority of the code should not be dealing withByteBuf - For the users directly dealing with
ByteBuf, the simple rule will be to unconditionally release it after they are done processing with theByteBuf. There are no special cases of thinking about in which scenarios (same thread or different) one should release theByteBufand 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
ByteBuffrom netty but there was no subscriber. In this case theByteBufis unconsumed andRxNettywill release such aByteBuf - RxNetty passed a
ByteBufto a subscriber which cached theByteBuf, which no code consumed. In this case, there should be an explicit dispose functionality available that should discard all unusedByteBuf. 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.