[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-net-dev
Subject: Re: HTTP 2 client API
From: Wenbo Zhu <wenboz () google ! com>
Date: 2015-08-27 22:08:58
Message-ID: CAD3-0rP4YK11j2knEfVbywDay_jdP6QL5h3mqkP5vSL0LacZ1w () mail ! gmail ! com
[Download RAW message or body]
By NIO2, I meant the following style of flow-control (back-pressure), in
pseudo code:
channel.notifywhenreadable(callback) // edge trigger ideally
channel.notifywhenwritable(callback)
int channel.availablebytes();
int channel.read(int, buf); // always from callback
int channel.write(buf); // always from callback
HTTP always assumes a byte-stream transport (even over UDP), and the above
flow-control style is easy to understand and maps well to the underlying
OS/transport.
There could be other variants to the above style, but if "Flow" is the
future, then there is no point to invent another style IMO.
- Wenbo
On Fri, Jul 31, 2015 at 11:52 AM, Simone Bordet <simone.bordet@gmail.com>
wrote:
> Hi,
>
> On Fri, Jul 31, 2015 at 8:37 PM, Wenbo Zhu <wenboz@google.com> wrote:
> >> > Or we follow the NIO2 model (readiness),
> >>
> >> Please no ! :)
> >
> > Ignoring the epoll part, is the issue in the API styles or the actual
> model?
>
> https://webtide.com/on-jdk-7-asynchronous-io/
>
> and
>
> http://www.slideshare.net/SimoneBordet/servlet-31-async-io, from slide
> 22 onwards.
>
> NIO2 is not an API I would like to see replicated/used in HttpClient.
>
> I know of people that are already upset with the current API because
> it forces too much allocation.
> That's because of the API, not because of the implementation.
>
> Now, perhaps these people are at one extreme of the spectrum, but
> certainly it is something we want to care about for an official JDK
> API.
> For example, the current API forces the allocation of a URI object for
> every request. That may be saved by changing the API (or supporting an
> overloaded version that takes a String).
>
> Me, I'd like to get the semantic right first, and then look at
> opportunities for improving performance.
>
> --
> 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
>
[Attachment #3 (text/html)]
<div dir="ltr"><div>By NIO2, I meant the following style of flow-control \
(back-pressure), in pseudo \
code:</div><div><br></div><div>channel.notifywhenreadable(callback) // edge \
trigger ideally</div><div>channel.notifywhenwritable(callback)</div><div><br></div><div>int \
channel.availablebytes();</div><div>int channel.read(int, buf); // always from \
callback <br></div><div>int channel.write(buf); // always from \
callback</div><div><br></div><div>HTTP always assumes a byte-stream transport (even \
over UDP), and the above flow-control style is easy to understand and maps well to \
the underlying OS/transport.</div><div><br></div><div>There could be other variants \
to the above style, but if "Flow" is the future, then there is no point to \
invent another style IMO.</div><div><br></div><div>- \
Wenbo<br></div><div><br></div><div><div class="gmail_extra"><br><div \
class="gmail_quote">On Fri, Jul 31, 2015 at 11:52 AM, Simone Bordet <span \
dir="ltr"><<a href="mailto:simone.bordet@gmail.com" \
target="_blank">simone.bordet@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi,<br> <span class=""><br>
On Fri, Jul 31, 2015 at 8:37 PM, Wenbo Zhu <<a \
href="mailto:wenboz@google.com">wenboz@google.com</a>> wrote:<br> >> > Or \
we follow the NIO2 model (readiness),<br> >><br>
>> Please no ! :)<br>
><br>
> Ignoring the epoll part, is the issue in the API styles or the actual model?<br>
<br>
</span><a href="https://webtide.com/on-jdk-7-asynchronous-io/" rel="noreferrer" \
target="_blank">https://webtide.com/on-jdk-7-asynchronous-io/</a><br> <br>
and<br>
<br>
<a href="http://www.slideshare.net/SimoneBordet/servlet-31-async-io" rel="noreferrer" \
target="_blank">http://www.slideshare.net/SimoneBordet/servlet-31-async-io</a>, from \
slide<br> 22 onwards.<br>
<br>
NIO2 is not an API I would like to see replicated/used in HttpClient.<br>
<br>
I know of people that are already upset with the current API because<br>
it forces too much allocation.<br>
That's because of the API, not because of the implementation.<br>
<br>
Now, perhaps these people are at one extreme of the spectrum, but<br>
certainly it is something we want to care about for an official JDK<br>
API.<br>
For example, the current API forces the allocation of a URI object for<br>
every request. That may be saved by changing the API (or supporting an<br>
overloaded version that takes a String).<br>
<br>
Me, I'd like to get the semantic right first, and then look at<br>
opportunities for improving performance.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Simone Bordet<br>
<a href="http://bordet.blogspot.com" rel="noreferrer" \
target="_blank">http://bordet.blogspot.com</a><br>
---<br>
Finally, no matter how good the architecture and design are,<br>
to deliver bug-free software with optimal performance and reliability,<br>
the implementation technique must be flawless. Victoria Livschitz<br>
</div></div></blockquote></div><br></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic