> > Yes, sure - we will upgrade at some point of > > time. But since upgrading all our servers will be some work, that may > > not happen right away. > > Upgrading mod_jk is the least painful of all of these, and the most > likely to affect you. > [Pantvaidya, Vishwajit] I understand and agree and will push for this - but most admins are conservative and so I am not harboring high hopes for success in this.
> > Here are figures from 3 of the servers which > > have not yet run out of threads (so the thread count does not add up > > to 200). I have taken these late at night when no users are present, > > so I was expecting all threads to be Waiting for tomcat thread-pool. > > > > 1. Total TP-Processor threads 48, Waiting 46, Runnable 2 > > 2. Total TP-Processor threads 40, Waiting 29, Runnable 11 > > 3. Total TP-Processor threads 120, Waiting 7, Runnable 113 > > Are you sure you aren't seeing any traffic, even that late at night? > What if you watch the access logs? Are there requests actively being > serviced? > [Pantvaidya, Vishwajit] I was "tail"ing the logs - there were no accesses. > > Do you think this could be because of the > > application? I was under the impression that there is some tomcat > > config parameter that controls this - which was set to 4. > > No, Tomcat uses precisely 1 thread to handle each incoming HTTP request. > If keepalives are used, multiple requests may be handled by the same > thread before it is returned to the pool, or different threads may be > used to serve different requests from the single connection, but in > either case, no more than 1 thread will be used to service a single HTTP > request. > [Pantvaidya, Vishwajit] Could this happen if upon my http browser request, the app could be spawning multiple redirects in quick succession leading tomcat to create multiple threads. Any other thoughts why I could be seeing tomcat spawn threads in multiples of 4? > >>> My workers config is: > >>> > >>> Worker...type=ajp13 > >>> Worker...cachesize=10 > >> Are you using the prefork MPM? If so, cachesize should be /1/. > > > > [Pantvaidya, Vishwajit] Could you please elaborate. What is the > > prefork MPM? > > The MPM is the concurrency strategy employed by Apache httpd. Either you > are using the "prefork MPM" which starts multiple httpd processes to > handle requests, or you are using the "worker MPM" which starts multiple > threads to handle requests. Actually, mod_jk should be able to > auto-detect the appropriate cachesize (called connection_pool_size, > now), so you shouldn't have to set this. > [Pantvaidya, Vishwajit] Ok thanks. "httpd -l" showed perfork.c. I guess that means we are using prefork MPM. So our cachesize should be 1? Our mod_jk version is 1.2.15 - will that also auto-detect the cache-size? > >>> Worker...cache_timeout=600 Worker...socket_keepalive=1 > >>> Worker...recycle_timeout=300 > >> Are these timeouts necessary? Why not simply let the connections > >> stay alive all the time? > >> > > [Pantvaidya, Vishwajit] Sure we could. But for any production change, > > I would have to offer a good enough reason. > > What was the "good enough reason" to set those timeouts in the first > place? > [Pantvaidya, Vishwajit] I agree - but again as I mentioned above because the admin will be conservative about any changes, I need to have a strong reason. Also when you say let the connection stay alive, does that mean let the TP-Processor thread remain in Waiting state / Runnable state? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
