On Wed, 2011-09-14 at 23:37 -0700, Rajiv Mordani wrote:
> So are you saying that you don't want the WriteListener and ReadListener
> but more the APIs like the NIO2 as you suggest below? Also would you add
> them to the InputStream and also create a ServletWriter as Shing Wai
> suggested earlier?
I doubt the NIO 2 style API is appropriate, because it might be
extremely inefficient.
If, for example, 1MB of data is available for reading, the NIO 2 version
has to make (with an 8KB buffer) 128 callback invocations. The initial
solution will simply do 128 reads on the stream using his byte[8192]
while staying in the application context all the time, until the ready
flag switches.
Another problem is the wrapping capability by a filter (to process bytes
being read or sent), which looks a lot more complex to do.
On 9/14/11 5:46 PM, Greg Wilkins wrote:
> Simple usage would be possible with the preallocation provided by
asDest:
>
> ServletInputStream in=request.getInputStream();
> byte[] buf = new byte[4096];
> Future<Integer> result = in.read(ByteBuffer.wrap(buf,0,buf.length))
>
> // do something else....
>
> result.get(10,TimeUnit.SECONDS);
I don't quite understand why this is a good design over the usual
blocking IO. Doing:
ServletInputStream in=request.getInputStream();
// do something else....
byte[] buf = new byte[4096];
int result = in.read(buf);
Will block for the same exact amount of time (minus the ability to set
the timeout in the same call, of course, but I don't think the
application should be dealing with timeouts at all, and if it really
must it would not be good to hardcode it). Without a completion handler
(= a callback), I don't see any gain over the blocking API we have at
the moment.
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc