> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Tuesday, November 22, 2011 3:44 PM > To: Tomcat Users List > Subject: Re: Thread executor question > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > DAvid, > > On 11/22/11 3:57 PM, David Dabbs wrote: > > We're going to be upgrading some vintage version 6 Tomcats to TC 7. > > > > > > I was wondering if there's any migration guide, in particular any > > discussion of the advantages to using thread pools/executors. > > So, you already have two responses about reading the documentation :( >
Yes, which I should have done. > In terms of actually using Executors, I wound say that you definitely want > to use one (or more). Here are a couple of reasons: > > 1. You can unify all request processor threads under one roof: the > executor can be shared among connectors, so you have a single pool > of threads for servicing requests instead of having to have several > pools, all of which have a large number of threads "just in case". > > 2. Executor thread pools can reduce the number of active threads > when traffic is low. This will free-up memory on the server during > slow times and make the server (slightly) more responsive as well. > > There really doesn't seem to be a reason not to use an Executor. > > Note: if you are making loopback-requests (that is, a thread makes an HTTP > (or other) connection back to Tomcat itself for some reason like an HTTP > include, etc.) then you might want to make sure that you use a separate > pool for the loopback requests. Depending on the volume of these requests, > you can deadlock your server if you're not careful: if you get N requests > that trigger a loopback request, you'll get N loopback requests for a total > requirement of 2*N request processors. > > It's conceivable that, if you have N request processors, N requests will > arrive and trigger N loopback requests, none of which can be accepted > because the original N request processors are stuck waiting on the loopback > requests. Eventually, everything should time-out, but you can get yourself > a few minutes of lock-up if you're not careful. > > To be sure, that's a contrived scenario and would "never happen"... > until it happens to your server under load and someone says "wow, we never > thought that would happen". > > - -chris Thank you, Chris. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk7MF6QACgkQ9CaO5/Lv0PBhdQCdEjNC/lvDKqpmZqejniHCfw3h > vmAAoKJ+IGOYag5M+/q3OjhI+cLgeunh > =5cjn > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1411 / Virus Database: 2092/4032 - Release Date: 11/22/11 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
