On Wed, Dec 6, 2017 at 6:31 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: > Viktor, > > The reference to byte buffer pools is not relevant here. They were > introduced as a performance optimization that allowed better reuse of > byte buffers between the socket channel and the SSL engine, in the > implementation. That's all, nothing more. They have no bearing on the > API, and this JEP is not proposing to make any changes in the NIO area.
+1, that was my fault, sorry about that. > What is relevant is the use of byte buffers as a Flow of request and > response body data. The API provides no mechanism for reuse, or pooling, > of these byte buffers ( it did in a previous revision but was removed > because of its complexity ). The latest version of the API for > BodySubscriber [1] contains the following: “... the ByteBuffers, > once passed to the subscriber, are no longer used by the HTTP client.”, > and the BodyPublisher [2] contains: “Instances of ByteBuffer published > by the publisher must be allocated by the publisher, and must not be > accessed after being handed over to the library.". Just out of curiosity, what kind of issues came up? What did the mechanism look like - was it just a callback to return depleted buffers to the HTTP client or user (as appropriate)? It sure would be nice to somehow finally tackle the problem of direct buffer allocation, pooling, and freeing for good; it's a bit of a nightmare right now. The lack of a good, standard pooling strategy is a big part of what makes me nervous about introducing an entire new async paradigm based on buffers, particularly with no possibility for pooling or reuse. I have many thoughts in this area (*crowd groans*) but it would be interesting to know what practical problems were encountered. > The API uses byte buffers as carriers of data in a way that is > consistent with other APIs. In the case of the publisher, it is the > responsibility of the user to allocate the buffer and pass it to the > HTTP Client, after which it should not be modified by user code. In the > case of the subscriber, once the byte buffer is passed to `onNext`, it > is then the sole responsibility of the subscriber. > > The primary motivation for the use byte buffers, as described above, is > to provide maximum flexibility to an implementation to avoid copying > and buffering of data. Is my reading of the API correct in that flow control is happening in terms of buffers, not of bytes? Could there ever be any odd effects from very small or very large buffers passing through the plumbing? -- - DML
