jsr340-experts@servlet-spec.java.net

[jsr340-experts] Re: Candidate for Servlet 3.1 Early draft review

From: Remy Maucherat <rmaucher_at_redhat.com>
Date: Wed, 29 Feb 2012 10:17:47 +0100

On Tue, 2012-02-28 at 11:19 -0800, Shing Wai Chan wrote:
> I have enclosed the candidate Servlet 3.1 Early draft review with change
> bars and the associated javadoc.
> The source code can be found at
> https://svn.java.net/svn/glassfish~svn/trunk/api/javaee-api/javax.servlet .
> For a list of changes, please look at the status chapter.
> Please give us feedback by Mar 6 (next Tue).

Some feedback focused exclusively on the upgraded connection section,
since it is brand new.

I understand the reasons for the addition of the upgraded connections
and I am now ok with the concept, but I have reservations about how they
are specified at the moment.

- Half closes. What is the use of that exactly ?

- I don't think using ServletIS and ServletOS in this API is a good
idea. In particular, ServletOS.flush(), ServletIS.readLine() and the
ServletOS.write(byte[]) with its blocking semantics (the full array must
be written) all seem to be a problem. I think read should instead
provide only one method: read(ByteBuffer) (and write would have
write(ByteBuffer)). With both being allowed to read or write 0 bytes,
probably. Or something like that.

- Using Read/WriteListener is not optional in this part, unlike for
regular Servlet 3.1, which means blocking IO is not available. I'm
skeptical about the write notification, which has the potential of being
called all the time.

- No notifications of timeouts. Everything is considered an error, with
a throwable included, and separated between input and output. That seems
very odd.

- No provision for sleeping and resuming beyond IO triggered events,
like the Servlet 3.0 async capability is providing. Protocol handler
could include a resume(WebConnection) and WebConnection could have a
suspend (or sleep) method. Although this could be done by the protocol
handlers, there could be concurrency issues between the thread pool it
would use and the IO operations done by the container. So adding the
feature would allow the container to provide full thread management like
it does for Servlet 3.0 and 3.1.

Thanks,
-- 
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc