-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/02/2014 06:03, Christopher Schultz wrote: > All, > > 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?
Maximum number of connections in the poller. I'd simply remove it from the table. It doesn't add anything. > 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 means simulated blocking. The low level writes use a non-blocking API but blocking is simulated by not returning to the caller until the write completes. > It is important to make that distinction since the end user (the > code) can't tell the difference? The end user shouldn't be able to tell the difference. It is important and it indicates that there is some overhead associated with the process. > 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? Correct. (excluding sendFile, async, WebSocket, Comet) > 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. Correct. > 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? Correct. Once request processing starts (i.e. after the request headers have been read) the same thread is used. Up to that point, different threads may be used as the input is read (with the NIO connector) using non-blocking IO. > Lastly, does anything change when Websocket is introduced into the > mix? Yes. Lots. > For example, when a connection is upgraded from HTTP to Websocket, > is there another possibility for thread-switching or anything like > that? Yes. Everything switches to non-blocking mode (or simulated non-blocking in the case of BIO). > Or is the upgrade completely-handled by the request-processing > thread that was already assigned to handle the HTTP request? The upgrade process is handled by the request processing thread but once the upgrade is complete (i.e. the 101 response has been returned) that thread returns to the pool. > 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? The upgrade is permanent. When the WebSocket processing ends, the socket is closed. > 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). Either. It depends how the upgrade handler is written. WebSocket uses Servlet 3.1 NIO so everything becomes non-blocking. > 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. I'd really encourage you to spend some time poking around in the low-level connector code debugging a few sample requests through the process. Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTDFTxAAoJEBDAHFovYFnnoNsP/3LyTwEMrXKiFmpsNJE8XCQz jodWqXzmLntm5dP3JydR9oXGHz4Bo3++E8FoTnoUb6D1cikdJcMt6WWVtWJegyQx NmLDk8fxHRuAsHqvOW0PZRBxH/TkUwavNkS9nZJGNBUmm2N50LHU7kb/FNYGmVXR qQcSwjRT2hV6C8gSMrAR3b9HgtTl9A+Ny/hoyynglkV99YjcEOMlBbXnSlVldAq+ f+byMRqSOx1YxEsAwHwyDxDnqZB52BI7Cm5INu46ntzlByIK1Hg6c6e0FYpdhnnA 8wNMOy42GtUhjDxcWTTpSVxA6O9XMEB8gG1AXZKBfkrL32sfwuENcu8Z+VLe6Ww2 XuBPdq/BvYm1cyn7CiHzwDb6ScSzxvO/hZTmqwkFD8pxq023uHMaggdwK45juO5l NWpauRRAoWJ7fxHf12RqLji5E5bAfAjlxAcaQVDv8JLNY8CAv9Xo+FNb1NwMStmL 0PzYB8Nq0+/97XgxVxJHINdXIuvPj/+ZmKowicLZWlLZ5r27vzEZwonh1A0/VBDi +t25dNY6Vts0H2KWnCF5gncH8N30d+52Nj029ao3kKFDV0gHymUuutoo5ySqdbWm C795Dyx3qWJ71K1J451Bvw68HG8Gx4QZeRLwCgxcGhRFj/+PG4AZBd829sXci6bA 2lc+QR73ywTZ0Xo6FvjF =Vefm -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
