RFR: 8087112: HTTP API and HTTP/1.1 implementation

[Michael McMahon]

On 28/09/15 11:23, Simone Bordet wrote:
> Hi,
>
> On Mon, Sep 28, 2015 at 11:38 AM, Michael McMahon
> <michael.x.mcmahon at oracle.com> wrote:
>> if the units are ByteBuffers say, then how do you convert a notification
>> of n units into a HTTP/2 window update (which has to be in bytes)?
> The implementation always has this information because it's the one
> that passed the ByteBuffer to the application, so it would be trivial
> for the implementation to make this conversion.
Trivial for n = 1 perhaps. For n>1 the implementation must keep track
of the size of each ByteBuffer (the number of bytes contained in each)
passed to the application and as each buffer is acknowledged, the window
can be updated by the corresponding number of bytes. So, while the buffers
themselves are typically of fixed size, the amount of data contained 
might not be
as each probably corresponds to a packet on the network (which can vary 
in size obviously).
I think it's a little odd, but is doable.

Another question is what value would be application/response processor use
as the initial window size? Without knowing something about the likely 
buffer
size, it is hard to know what to use (except the value 1).

>> Perhaps, if n is required always to be equal to 1, then you could do it
>> because you would always be referring to the last buffer received
>> but it seems trickier if n > 1.
> Consider onRequestBodyChunk(ByteBuffer) as Flow.Subscriber.onNext(ByteBuffer).
> What an application wants to say here is "give me another buffer", not
> "give me 42 bytes".
>
> The 42 bytes are irrelevant because the implementation won't certainly
> read 42 bytes *only* from the network: it typically has buffers of
> certain size that it reuses for network reads.
>
> The application will always be in control if it really needs 42 bytes,
> whatever length is the buffer that the implementation passes to it.
> It can buffer the bytes if they're less than 42, it can slice the
> buffer if they're more than 42, it can do whatever it needs to do to
> comply with the 42 bytes requirement.
> What it needs from the implementation is just another ByteBuffer.
>
>> What I was saying was that completion of response also implies
>> competion of request (ie that it isn't notified until after both happens)
> Okay.
>
>> Why would it break the contract? Note, I am referring to
>> HttpRequest.cancel() not CompletableFuture.cancel()
> Okay.
> Still, there is no way to specify an async timeout (and the others I mentioned).
>
> Consider this:
>
> try
> {
>      response = responseFuture.get(5, SECONDS);
> }
> catch (TimeoutException x)
> {
>      // The response may have arrived after 5.1 s, but before we
> execute the code below.
>
>      // Aborting a request that is instead successful !
>      boolean cancelled = request.cancel();
>      if (!cancelled)
>      {
>          // May be succeeded or failed, try again.
>          try
>          {
>              response = response.get();
>          }
>          catch (Exception xx)
>          {
>              // Yuck
>          }
>      }
> }
>
> Note that HttpRequest.cancel() does not return a boolean to know
> whether the request has been really cancelled, or if it arrived in the
> meanwhile.
> I think it should (must).
>
> Now compare to this:
>
> try
> {
>      response = client.newRequest(uri).timeout(5,
> SECONDS).method("GET").response();
> }
> catch (TimeoutException x)
> {
>      // Request already atomically aborted by the implementation.
> }
>
> Note that the latter solution will work also for async timeouts:
>
> client.newRequest(uri).timeout(5,
> SECONDS).method("GET").responseAsync().handle((r, x) ->
> {
>      if (x instance of TimeoutException)
>          ;// handle timeout
> });
>
> The API to specify timeouts is the same for both sync and async cases.
>
> The idiom an application writer has to write when using
> Future.get(time) is just cumbersome, I would advice against any usage
> of Future methods in the API.
> CompletableFuture is fine, as long as you don't use the Future methods.
> If an application wants to use Future methods, they are on their own,
> but at least they are not forced to.
>

We might reconsider this. Currently there is no timeout for blocking
calls, which I guess is problematic.

Thanks
Michael