Hi,
On Mon, Sep 28, 2015 at 10:45 AM, Michael McMahon
<michael.x.mcma...@oracle.com> wrote:
> The API has already been approved and the first version to
> be integrated won't have all suggestions incorporated.
> But, it should be possible to address many of them in time
> for JDK 9 anyway.
Okay.
>> A) lack of backpressure,
>
> My current thoughts on this is to have credit based flow control
> window (similar to the Flow API) indicating the number of bytes
> that a HttpResponseBodyProcessor is willing to accept and this
> maps directly on to the HTTP/2 flow control window and the socket
> buffer when doing HTTP/1.
Bear in mind that application must have control over this, so you have
to expose an API that application can use to notify that they are done
with the content.
I am not sure the number of bytes is the right unit - my experience is
that you want to trade ByteBuffers as a unit, not the bytes they
contain.
This is also critical for buffer reuse and to avoid nasty surprises on
who owns the buffer.
To be clear:
class MyResponseProcessor implements HttpResponseBodyProcessor
{
void onResponseBodyChunk(ByteBuffer buffer)
{
writeAsyncToDisk(buffer, new CompletionHandler()
{
success: <tell implementation it can call onResponseBodyChunk again>
failure: <tell implementation to abort response>
});
}
}
>> B) missing "request complete" event
>
> When you suggested this, I decided to split the API so that requests
> and responses complete independently, but this was too drastic a change
> and most use-cases are satisfied by completion of both request and response.
I am not sure I follow here.
There is currently no way for an application to be notified of request
completion, so there is no way to be notified of completion of both
request and response, only of response.
Are you saying that most use cases will require this, and so it needs
to be addressed, or are you saying that it is already done in a way
that I could not see ?
Can you expand on this ?
> It's also possible to be notified of request completion through the
> request processor. It should be straight forward to wrap any request
> processor
> in a processor which provides a CompletableFuture for completion of the
> request.
You mean HttpRequestBodyProcessor ?
I don't think it's invoked if there is no body, and it has no
onRequestBodyComplete() method.
Can you expand again ?
>> C) missing timeouts (CompletableFuture.get(time) is obviously not the
>> right semantic)
>
> CompletableFuture.get() is at least useful for notifying timeouts.
There is the need for a completely async timeout.
Plus, the semantic of Future.get() is that the time you specified to
get() has passed.
There is no implied semantic that the request has been aborted, and
aborting the request via cancel() would break the Future.get(time)
contract.
Really, Future.get(time) is the wrong semantic, you don't want to use that.
I suggest that blocking methods throw TimeoutException, and that async
methods get notified with a TimeoutException on their
CompletableFuture.
> The question then is what to do next and what was missing was
> cancellation, and that has been added. Does that not suffice?
Nope. As said above, there is no async timeout, no idle timeout, no
total (request + response) timeout, which are in my experience the 3
most requested features about timeouts.
--
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
