On Wed, 2011-09-14 at 09:26 +1000, Greg Wilkins wrote:
> On 13 September 2011 18:03, Remy Maucherat <rmaucher_at_redhat.com> wrote:
> 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.
Yes, that does sound significantly more expensive. Also, the data would
need a lot more async operations to be read (the method from the
proposal reads until all data that is really available is read).
> 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.
I don't see how Rajiv's proposal has worse performance by design (unlike
the future based design, where the best possible impl is still going to
be slower).
I said performance would go down in some cases, but that is compared to
the java.io that is there by default right now. Servlets use blocking IO
(until now), and generally java.io has the best throughput for that.
Also, all non blocking IO tends to have more bugs and platform
limitations than blocking IO. But this is not to say this mustn't be
done, but rather that there's going to be a cost, and we should be
prepared to justify it.
> + 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 this is a nice for client apps, but less nice for building a
server with the best scalability. The new File IO should be useful
however for the server impl.
> 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
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc