On 9/13/11 4:26 PM, Greg Wilkins wrote:
> On 13 September 2011 18:03, Remy Maucherat<rmaucher_at_redhat.com> wrote:
>> - It doesn't actually help many people right now. The complexity in the
>> application is (much) higher, so until frameworks do it automagically,
>> it's not going to be used.
>
> I think it would be appropriate to have a discussion about what are
> our requirements for this API. Is ease of use a higher priority over
> scalability and performance?
>
> For example, the async IO features in java 7 are actually pretty easy
> to use, but they don't scale all that well. They are based around a
> Future pattern like:
>
> Future<Integer> read(Buffer data)
>
> This is simple to use, but suffers from the scalability issue that the
> buffer has to be allocated at the time the read is scheduled rather
> than when data actually arrives to be read.
Note that in JDK 7, AsynchronousByteChannel, besides method similar to
above, we have
<A> void read(ByteBuffer dst, A attachment, CompletionHandler<Integer, ?
super A> handler)
> My thoughts in this regards to this are:
> + if you want outright performance, then working behind a generic
> portable API is always going to be a hindrance.
> + Those who want the last nano second are probably going to go
> proprietary anyway.
> + Java 7 appears to have made the call of async usability over
> outright scalability, so perhaps we should follow them?
>
> I think there is scope to copy many of the async patterns in NIO.2
> (such as futures) without actually needing to expose any specific
> NIO.2 APIs. If we were to do that, then at least developers familiar
> with NIO.2 will also be able to easily understand similar features in
> the servlet API.
>
>
>
> Of course - there is the contrary position - that perhaps we should
> not bother with exposing async IO anymore. Instead continue to
> provide higher level APIs (eg File upload in 3.0 and Websockets in
> 3.1) that individual containers can implement with async IO behind he
> scenes
>
> cheers