Mark, On 2/27/14, 12:56 PM, Christopher Schultz wrote: > Mark, > > On 2/25/14, 3:31 AM, Mark Thomas wrote: >> 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. > > Okay, thanks. > >>> 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. > > That's what I was thinking. Thanks for confirming.
Another quick question: during the sim-blocking for reading the request-body, does the request go back into the poller queue, or does it just sit waiting single-threaded-style? I would assume that latter, otherwise we'd either violate the spec (one thread serves the whole request) or spend a lot of resources making sure we got the same thread back, etc. Thanks, -chris
signature.asc
Description: OpenPGP digital signature
