On Fri, 2012-03-30 at 19:23 +0200, Oleksiy Stashok wrote:
> Once we don't have integer parameter neither in canWrite nor in
> notifyCanWrite, AFAIU we can guarantee that if canWrite() returned
> true - next "write" method call (despite the size of the passed data)
> will not block.
That's what I am doing (and it works). It is necessary IMO since the for
example char methods of the writer are relatively unpredictable in terms
of output size. The downside is the resource use, but as you mention,
regardless of the technique employed, the memory is used until the bytes
are written.
> Just an idea, may be it's not good, but anyway:
> 1) When dealing w/ byte[] (existing OutputStream API) we go w/ Remy's
> suggestion, which may involve internal byte[] copying. IMO this
> approach is clear and very intuitive to Servlet developers, even
> though it's not optimal in some cases.
This is the write(byte[]) all my comments refer to ...
> 2) Introduce new method(s) (Servlet)OutputStream.write(ByteBuffer),
> which will be implemented in a copy-free fashion. We'll document the
> fact, that developer can reuse the ByteBuffer only after making sure
> it's not used by container.
... since from what I know write(ByteBuffer) hasn't been added yet.
Certainly the application would have to give ownership of its buffer to
the container. Getting it back when the write listener is called is
possible.
OTOH, a write(ByteBuffer) with copy-free fanciness in mind cannot
support any HTTP encoding, as in the application bytes cannot be
modified (chunking, compression, etc). In Tomcat, the sendfile feature
uses a content-length, without compression, to work. So in HTTP Servlets
write(ByteBuffer) is quite specific, but it fits in a more generic way
into the connection upgrade API.
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc