Thanks for those clarifcations, Chris, I really appreciate it! -- Cheers, √
On Dec 6, 2017 13:31, "Chris Hegarty" <chris.hega...@oracle.com> wrote: > Viktor, > > I would like to address your first comment only, as your question is > directed to someone else. > > > On 6 Dec 2017, at 10:01, Viktor Klang <viktor.kl...@gmail.com> wrote: > > .. > > I think you raise some valid concerns, particularly with the byte buffer > pools. > > The conversation got off to a bad start as there was a misunderstanding > about what was actually being proposed, so I would like to clear that > up. > > 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. > > 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.". I accept that this > could be made more clear in the API. > > 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. > > --- > > Through contacts from Viktor, we have recently received some feedback on > the use of the body subscriber and publisher in the API. This feedback > is very helpful and we will soon send out a proposal that will better > support integration with existing publishers and subscribers. [ I will > work with Viktor to bring this to the mailing list ]. > > > -Chris. > > [1] http://cr.openjdk.java.net/~chegar/httpclient/javadoc/api/ > jdk/incubator/http/HttpResponse.BodySubscriber.html > [2] http://cr.openjdk.java.net/~chegar/httpclient/javadoc/api/ > jdk/incubator/http/HttpRequest.BodyPublisher.html >
