tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Connectors, blocking, and keepalive
Date Tue, 25 Feb 2014 06:03:15 GMT

I'm looking at the comparison table at the bottom of the HTTP connectors
page, and I have a few questions about it.

First, what does "Polling size" mean?

Second, under the NIO connector, both "Read HTTP Body" and "Write HTTP
Response" say that they are "sim-Blocking"... does that mean that the
API itself is stream-based (i.e. blocking) but that the actual
under-the-covers behavior is to use non-blocking I/O? It is important to
make that distinction since the end user (the code) can't tell the
difference? Unless there is another thread pushing the bytes back to the
client for instance, the request-processing thread is tied-up performing
I/O whether it's doing blocking I/O or non-blocking I/O, right?

Third, under "Wait for next Request", only the BIO connector says
"blocking". Does "Wait for next Request" really mean
wait-for-next-keepalive-request-on-the-same-connection? That's the only
thing that would make sense to me.

Fourth, the "SSL Handshake" says non-blocking for NIO but blocking for
the BIO and APR connectors. Does that mean that SSL handshaking with the
NIO connector is done in such a way that it does not tie-up a thread
from the pool for the entire SSL handshake and subsequent request?
Meaning that the thread(s) that handle the SSL handshake may not be the
same one(s) that begin processing the request itself?

Lastly, does anything change when Websocket is introduced into the mix?
For example, when a connection is upgraded from HTTP to Websocket, is
there another possibility for thread-switching or anything like that? Or
is the upgrade completely-handled by the request-processing thread that
was already assigned to handle the HTTP request? Also, (forgive my
Websocket ignorance) once the connection has been upgraded for a single
request, does it stay upgraded or is the next (keepalive) request
expected to be a regular HTTP request that can also be upgraded? In the
event that the request "stays upgraded", does the connection go back
into the request queue to be handled by another thread, or does the
current thread handle subsequent requests (e.g. BIO-style behavior,
regardless of connector).

I'm giving a talk at ApacheCon NA comparing the various connectors and
I'd like to build a couple of diagrams showing how threads are
allocated, cycled, etc. so the audience can get a better handle on where
the various efficiencies are for each, as well as what each
configuration setting can accomplish. I think I should be able to
re-write a lot of the Users' Guide section on connectors (a currently
mere 4 paragraphs) to help folks understand what the options are, why
they are available, and why they might want to use one over the other.


View raw message