Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: unknown (athena.apache.org: error in processing during lookup of
 thurston@nomagicsoftware.com)
Date: Sat, 23 Mar 2013 08:05:31 -0700 (PDT)
From: igaz <thurston@nomagicsoftware.com>
To: dev@tomcat.apache.org
Message-ID: <1364051131292-4996773.post@n6.nabble.com>
Subject: Getting my head around NIO 'simulated' blocking (trying to)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

So I won't bury the lede: what exactly (and why) is Tomcat doing 'simulated'
read blocking when using the NIO connector? 

I've done some due diligence including downloading the latest source
(7.0.37) and searching the tomcat mailing lists.
Firstly, to make things simpler, let's take comet processing and writes off
the table.

In the tomcat doc, there is the nice table that compares the various http
connectors and it reads this about nio:
Read HTTP Request:  non-blocking (I assume that means read all of the http
request headers)
Read HTTP Body: sim blocking (e.g. in a POST)

I've browsed the code and the NIOEndpoint.Acceptor and NIOEndpoint.Poller
all essentially make sense and look familiar to someone who has some
experience with Java NIO
But there's quite a bit of code to look at (and lots of abstraction) and I
haven't got much further than there.
What I don't understand is the HTTP Body: sim blocking part.
Thinking about that, the only conclusion I can draw is that
HttpRequest.getParameter('xxxx') potentially blocks?!?! i.e. tomcat is
'deferring' the parsing of the HTTP Body (as in the case of a POST) until
the application Servlet 'asks' for it?
I've always assumed that the HTTPRequest that is passed to the Servlet is
fully formed.
In one of the posts I saw a comment that (I believe Filip) mentioned
something about Servlets that call getInputStream()
requiring simulated blocking.  But why would any servlet code ever do that? 
After all, it has the HttpRequest which is a nice abstraction over the input
stream (hmm, maybe when reading uploaded files)?

So the first question is (assuming my inference is correct), why use
simulated blocking at all?  Just read the entire http request (headers and
body) until you detect that the request is complete (and using standard NIO
techniques, viz. a selector).  Is there something in the servlet specs that
proscribes that?

And the second question is how?  I guess you invoke
SocketChannel.configureBlocking(true) and then do SocketChannel.reads()

It seems that using NIO to only read the HTTP headers vitiates the
performance benefits of NIO somewhat and I'm sure you're doing it for a good
reason . . .


--
View this message in context: http://tomcat.10.n6.nabble.com/Getting-my-head-around-NIO-simulated-blocking-trying-to-tp4996773.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org