On 3/8/2012 8:56 PM, Greg Wilkins wrote:
> On 8 March 2012 20:25, Remy Maucherat<rmaucher_at_redhat.com> wrote:
>> On Thu, 2012-03-08 at 16:45 +1100, Greg Wilkins wrote:
>>> No, the servlet has to check each write to see if all the passed bytes
>>> were written, and if not, then give up the thread and wait for the
>>> canWrite callback.
>> It should be obvious that most small writes are going to be done
>> immediately, so the boolean flag stays the same as true, and the
>> application can continue writing (= zero cost).
> Asynchronous IO APIs should not be used in this way. They are not
> intended for code like:
>
> asyncStream.write("<h1>");
> asyncStream.write(mytitle);
> asyncStream.write("/<h1>");
>
> Because any of those writes could return 0 or< all bytes written and
> the application code would be unworkable.
> Instead, these writes should be to a buffer and then the entire buffer
> can be written via the asyncIO.
>
> If for some reason, you really do have multiple short contents to
> write, then that could be handled with a gather write:
>
> public void write(ByteBuffer...
> buffer,CompletionHandler<Boolean,AsyncContext> handler)
> {
> }
>
> Thus the completion handler would only be called back after all the
> short writes had been done, not after each of them.
>
> Also note that there is no requirement that the call back be done in a
> different thread. If the write manages to write all the content, then
> it could directly call the completion handler.
The other issue with the API that you are suggesting is that the app now
has to encode everything into a ByteBuffer
for writes and decode everything from the ByteBuffer for reads and
cannot use the Reader
and Writer for doing async IO.
>
>
>> Note: I think this was already discussed months ago when hesitating over
>> the style of the API, and Rajiv proposed the two main options (blocking
>> IO with flags, or NIO2 style). Did I miss something ?
> I think there was a discussion about if we should directly use the
> NIO2 API's directly. There was some concern about how efficient they
> were because their style requires read buffers to be allocated when a
> read is scheduled rather than when it occurs.
I still have concerns about this and that's the main reason why I didn't
go down
the route of having that style of APIs. I do have an AI to talk to Alan
Bateman from the discussions
to see why they did the NIO2 APis the way they did and I will follow
up with him and maybe
even invite him to come and talk to the EG about it, but in the mean
time I would like to keep the proposal
that we have and revisit this later if needed.
>
> I've used them a bit more since then and have warmed to the style
> somewhat. They certainly are simpler to use that traditional style
> async IO.
>
> I just really think we need to think REALLY hard before we go off an
> invent yet another IO style for use with just servlets
Agreed. Let me follow up with Alan Bateman from the JDK team who did the
NIO2 APIs and
get back to the EG as well.
Thanks
- Rajiv
>
> regards