-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/03/2014 16:56, Christopher Schultz wrote: > Mark, > > On 3/24/14, 5:37 AM, Mark Thomas wrote: >> 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. > > Understood, but there are say 1000 connections waiting in the > accept queue and only 250 threads available, if my connection gets > accept()ed, then I get to make as many requests as I want without > having to get back in line. Yes, I ave to compete for CPU time with > the other 249 threads, but I don't have to wait in the > 1000-connection-long line.
I knew something was bugging me about this. You need to look at the end of the while loop in AbstractHttp11Processor.process() and the call to breakKeepAliveLoop() What happens is that if there is no evidence of a pipelined request at that point, the socket goes back into the socket/processor map and the thread is used to process another socket so you can end up with more concurrent connections than threads but only if you explicitly set maxConnections > maxThreads which I would maintain is a bad idea for BIO anyway as you can end up with some threads waiting huge amounts of time to be processed. Given that this feature offers little/no benefit at the price of having to run through a whole pile of code only to end up back where you started, I'm tempted to hard-code the return value of breakKeepAliveLoop() to false for BIO HTTP. Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTMGaJAAoJEBDAHFovYFnn0lQP/A4TyL3Xqp/dd4nYJxtP1lXT omQfbVHYI61Qb1DZDLxjRmM4/9Qs1YUEImmyJLtG1YE7XqeiJhp7bcg4K8BOXKP1 V2Di9cqiRo4mFxmOSsk/86Gad0lnRafc+MetepOATpaDrSTYlCrkGpyjuNKHfbai nILsSiUGV1qlG/XPteJUrG5SwyphdUyKA2HpnPnMsYG5p4aO2Gj8e3tpF1eoKXSK IX1PEVxY5ur2UyZrX7Gz4ulz7DKtJN/w7r2iscR3ItxGgl3K6bBcWd6EaUKraCKW iBsPbFxzQe2AH0iPil6P+HCMenDpsc8D246FrIfL492hYcN8Zcui0EfwmpAcxFg9 M2yVS0X97vjo/L62OuQlj8WXOvCILlaeyh1zW8cjuz2ABw/loczc0WBZFVl7vkJe me58M38Eo0/jMZ8SFy+t9OREUXPY721l0+/I8h0ded57lsgrXXxTIdB8kT0YV2Ru XIaPrZafUg7rq413UC0lcSj6mhLwMtS/rusHwDY/RMLsx/1Wvyr1N4K0knDl16iy PMB5sEEKd/VmW4a1f9ZxBvb9/TmY/cPZxQ1p/hNi8QTkRyTDwA8bta+KKsjfG/Du drNDweML7AcI1X14PTqWgG/kNGVA+0YLvcgPeZPS021HTETzGAzcn93jT1xG15dU 06RFVeURXSNQsuMpWANR =Qv1g -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
