-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/03/2014 00:50, Christopher Schultz wrote: > Mark, > > On 3/23/14, 6:12 PM, Mark Thomas wrote: >> On 23/03/2014 22:07, Christopher Schultz wrote: >>> 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. >> >> Both. >> >> The socket gets added to the BlockPoller and the thread waits on >> a latch for the BlockPoller to data can be read. > > Okay, but it's still one-thread-one-request... /The/ thread will > stay with that request until its complete, right? The BlockPoller > will just wake-up the same waiting thread.. no funny-business? ;)
Correct. > Okay, one more related question: for the BIO connector, does the > request/connection go back into any kind of queue after the > initial (keep-alive) request has completed, or does the thread that > has already processed the first request on the connection keep > going until there are no more keep-alive requests? I can't see a > mechanism in the BIO connector to ensure any kind of fairness with > respect to request priority: once the client is in, it can make as > many requests as it wants (up to maxKeepAliveRequests) without > getting back in line. Correct. Although keep in mind that for BIO it doesn't make sense to have connections > threads so it really comes down to how the threads are scheduled for processing. Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTL/zwAAoJEBDAHFovYFnn7ZwQALSXf/WzpzXd1hj/TdfUCSlI e7m6vMP0EdzTG5WV1GcnWb4I/votVJEENhr1ApB+kMc00qrnvOxu/YPMaNjkd7J+ CqajYOYEobuWt4UAqGSk9QyLq9bjKNyzG8jN+q2AY3mVjjM019RzQhP2Wf3AdjOW v+Nu9j+A32vay/UcutEzxGvVEtmHTqW70B9o+43SqPuplJLzb6rGooq8JICsDn5g agTUynLqZEgxHyJ5d7b+ZnXcsFRcchfyZqNCDOCo7ULqS6y9jaqUZSrq8hDvOjMi 6LNH/mk6QVPuii3j0wZ8kmJFgK6Tb1DID6+gx7Xw8CHfmxi0P4Cf6L87CYMFo7AO dRB1IE5WeuRjxXlGS197NZ+l+fBQe24UNFw+Z0Uy38yqpIFjzvdxsZXihJGT6j2+ m4d01GJc4vbZR9le8BJuVLrb5rT7Dmk2Tg0nJmOHMmoGk/yioJ2/2pR+HqNAr9Uw cq1+qvS+773rGNm1z4ULcV0S5cpWikUIoQa+v17kfBDVzJiCY1HGJfJM29kLp8z+ M4KnyeACRcPu0RUZqV6DStd6am6uRZ3l3nQFRyBTKdW8lsSwjx3XOBQGC5k0yNZ7 z6O1mdFQH1+4i6hfWoTqPsjq85V/+BxEwNdXYNJBF0OSgAqOTHRKpxgIy3TIi4M2 AyXj6QGYgkXTnCKNTynL =O1Wm -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
