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? 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. Thanks, -chris
signature.asc
Description: OpenPGP digital signature
