Hi, On Tue, Oct 13, 2015 at 10:02 PM, Chris Hegarty <chris.hega...@oracle.com> wrote: >> Here is a proposed mechanism for managing buffers used by Listener. > > I think that this is quite good. There is clearly a need for the receiving > callbacks, onXXX methods, to allocate ( since they pass the payload > as a ByteBuffer ), so exposing, through a small surface area, an API > that gives better control over this allocation ( for the 0.1%that may > want to do this ), without impacting on the 99.9% that couldn’t > care less about it, seems reasonable. It is a nice side-effect that > pinning / explicit release can be built on top of this, albeit with a > small amount of work.
I am not sure I like it. This being a WebSocket API, I am not sure that exposing ByteBuffer pooling in the WebSocket API is a good idea. I agree that there is a need to configure this, but seems to me more an implementation detail or something you want to configure in a concrete implementation class, rather than in the API. IMHO there are other ways to solve the same problem than exposing a ByteBuffer pool API inside a WebSocket API. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
