On 07/04/16 14:19, Simone Bordet wrote:
Hi,
On Wed, Apr 6, 2016 at 4:08 PM, Michael McMahon
<michael.x.mcma...@oracle.com> wrote:
Hi,
This is the webrev for the HTTP/2 part of JEP 110.
http://cr.openjdk.java.net/~michaelm/8087124/webrev.1/index.html
Before I dive further into this, seems to me that the implementation
is blocking; not the API which are protected via dispatches to other
threads (that then block), but the I/O.
Is this deliberate ? I was under the impression the HTTP client wanted
to be non-blocking at its core ?
At the lowest level the implementation uses two threads per TCP
connection, one
for reading and one for writing. I do plan to change that to dispatch
from the selector
and execute the reads and writes asynchronously. It's not a particularly
big change,
but would prefer to do it after the first integration of this code.
The Stream layer above this behaves much the same as in Http/1.1. where it
uses a single thread invocation for sending each request body and
receiving each
response body. So, it's not exactly blocking. Nor is it entirely
asynchronous/non blocking.
- Michael
