On 3/7/2012 9:45 PM, Greg Wilkins wrote:
> On 7 March 2012 18:47, Remy Maucherat<rmaucher_at_redhat.com> wrote:
>
>> We have a big (unique) opportunity to provide an API which would do the
>> full thing efficiently, let's not waste it.
> Which is exactly why we have to consider a range of possibilities. I
> think it is worthwhile to consider an API based on the JDK7 style, but
> I accept that if it cannot be made efficient, then there is not point.
I certainly do have concerns about making this efficient.
>
>
>> I don't understand how it can be efficient, although I get the idea it
>> can provide most of the functionality.
>>
>> Besides encouraging using temp files,
> The write file API is there for static content not temp files. The
> idea is that the container can very efficiently use direct buffers to
> write a memory mapped file, so this has the potential to be even more
> efficient.
>
>
> The read file API may encourage temp buffers. So let's add a
> public<A> void read(ByteBuffer buffer, CompletionHandler<Boolean,
> AsyncContext> handler)
> {
> }
> that reads content into the buffer until it is full or EOF and then
> calls back the handler.
I am concerned about all the ByteBuffers that one could potentially have.
>
>
>> write(ByteBuffer) has to wait for the servlet to return, then call the
>> completion handler, before the servlet can write again. That's a large
>> lag between each write.
> Not at all. As soon as you have an AsyncContext you can call write, so
> immediately after startAsync. However as we'd want this for upgrade
> as well, perhaps the methods should be on request/response or some
> other entity that works for both. The key think is that they can be
> called as soon as the async mode is entered (via startAsync or
> upgrade).
Why would you want to tie this to startAsync? Is it really required to
have an AsyncContext
to do async IO?
>
> Once the write is complete, I don't see why the callback to the
> completion handler is any faster/slow than the callback to canWrite.
> The mechanism will be similar except the semantic is simpler.
>
> With the current proposal, the container has to detect a write that
> did not full write all the bytes passed and schedule a callback when
> the connection is again writeable. The application has to notice that
> not all bytes were written and give up the thread, remembering the
> unwritten bytes, and wait for the callback. Once the callback
> occurs, the app can write the remembered unwritten bytes and if that
> completes can go onto the next write.
The callback says how many bytes you can write. So
>
> With my proposal, the app writes the bytes and gives up the thread (or
> does something else). Once the container has written all the bytes, it
> calls back the application, which does the next write.
>
> For large content, you could expect many blocks and canwrite
> callbacks, so the current proposal would require a lot more call backs
> than my proposal.
But it comes at a cost of having all the ByteBuffers till the write has
completed. Also
what happens if the AsyncContext times out and then the read / write
hasn't completed?
>
>
>> On the async API we propose, it is possible the
>> servlet can continue writing, thus avoiding a costly round trip to the
>> container.
> 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.