Hi Chris,
Thanks for the review. I've incorporated your comments.
I'll push the current version today. Below is a webrev
of the exact changes. I will come back to other comments made
later and will make more changes then.
http://cr.openjdk.java.net/~michaelm/8087124/webrev.3/
Thanks,
Michael.
On 22 Apr 2016, at 22:51, Michael McMahon wrote:
> Hi,
>
> An updated webrev is available at:
>
> http://cr.openjdk.java.net/~michaelm/8087124/webrev.2/
>
> The main change is the removal of the permanently allocated
> two threads per TCP connection (for HTTP/2)
This is good.
Http2ClientImp
Hi,
An updated webrev is available at:
http://cr.openjdk.java.net/~michaelm/8087124/webrev.2/
The main change is the removal of the permanently allocated
two threads per TCP connection (for HTTP/2)
Now, all socket reads and writes are done by the selector thread
(writes also happen on other th
Hi,
On Wed, Apr 6, 2016 at 4:08 PM, Michael McMahon
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
API
I have already mentioned in 2 previous messages my feedback about the
API, but a few of my concerns ha
On 07/04/16 14:37, Simone Bordet wrote:
Hi,
On Thu, Apr 7, 2016 at 3:27 PM, Michael McMahon
wrote:
At the lowest level the implementation uses two threads per TCP connection,
one for reading and one for writing.
Ugh.
I do plan to change that to dispatch from
the selector
and execute the rea
Hi,
On Thu, Apr 7, 2016 at 3:27 PM, Michael McMahon
wrote:
> At the lowest level the implementation uses two threads per TCP connection,
> one for reading and one for writing.
Ugh.
> I do plan to change that to dispatch from
> the selector
> and execute the reads and writes asynchronously. It's
On 07/04/16 14:19, Simone Bordet wrote:
Hi,
On Wed, Apr 6, 2016 at 4:08 PM, Michael McMahon
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
i
Hi,
On Wed, Apr 6, 2016 at 4:08 PM, Michael McMahon
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 pro
On 07/04/16 11:28, Simone Bordet wrote:
Hi,
On Thu, Apr 7, 2016 at 12:22 PM, Michael McMahon
wrote:
Simone,
The webrev should include a patch file that you can apply to
the source tree. The link is at the top of the page (jdk.patch)
Tried that with
patch -p1 < jdk.patch
I get a lot of reje
Hi,
On Thu, Apr 7, 2016 at 12:22 PM, Michael McMahon
wrote:
> Simone,
>
> The webrev should include a patch file that you can apply to
> the source tree. The link is at the top of the page (jdk.patch)
Tried that with
patch -p1 < jdk.patch
I get a lot of rejects.
I am applying your HTTP/1.1 pa
> On 7 Apr 2016, at 11:20, Simone Bordet wrote:
>
> Can I ask how you guys apply webrevs to the JDK 9 source tree ?
> I would prefer to review in an IDE rather than in textual mode, but I
> have not found instructions on how to apply a webrev to a source tree.
Sure, each webrev should contain a
On 07/04/16 11:20, Simone Bordet wrote:
Michael,
On Wed, Apr 6, 2016 at 4:08 PM, Michael McMahon
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
Can I ask how you guys apply webrevs to the JDK 9 source tree ?
I w
Michael,
On Wed, Apr 6, 2016 at 4:08 PM, Michael McMahon
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
Can I ask how you guys apply webrevs to the JDK 9 source tree ?
I would prefer to review in an IDE rat
John,
It is not necessary to have access to the frames themselves to achieve this.
At the API level, in the HttpResponse.MultiProcessor type the onStart()
method
returns a BiFunction that is called for each incoming push promise. The
implementation
of that function (which is supplied by the use
Hi Michael,
All of HTTP/2 frame types aren't public APIs, then is there any way to
handle HTTP/2 at lower level?
For example, how to cancel server push? In theory, the client should
send a RST_STREAM frame with error code REFUSED_STREAM or CANCEL to the
server.
Best regards,
John Jiang
On 20
15 matches
Mail list logo