Mirek, Thank you for the response and confirming that the problem is between Tomcat and Apache. I will check the connections settings for both Tomcat and Apache and see if I can monitor what's going on between them.
As far as your JDBC problem, I do not have much to offer. This customer's configuration is much simpler - a single web/application/db server that is Internet facing. Since getting the removeAbandoned* settings correct we seem OK. That said, we know that there is still a JDBC connection leak "somewhere". Take care - Richard -----Original Message----- From: Mirek Kopriva [mailto:[EMAIL PROTECTED] Sent: Friday, December 09, 2005 2:31 AM To: Tomcat Users List; [EMAIL PROTECTED] Subject: Re: Tomcat 4.1 hang - maybe in JK connector Hi, We are solving similar problem right now. Setting the removeAbandoned increased the period between the stucking to 7 hours) What is your network configuration? Is there a firewall or something between tomcat and apache? We are getting stucked in communication between the jdbc driver in the tomcat instances and the database though (there is a firewall cluster between them). (the first thread on the stack is also SocketInputStream.read0(...), it goes down to jdbc driver's call on setAutocomit (). so we tried to do tcpdump on both database and the tomcat machine where it got stucked and we saw that the driver is sending acknoleadgemnt messages to the db, but can not get the packets back (that's whay it's stuck in the ' SocketInputStream.read0(...)' method, I guess). After a while the db starts responding but the comunication is still not good (lots of 'ack' packet). Because of that it can take from 1 to 20 minutes (pretty random) till the comunication gets back to normal and everything is fine. We are guessing it's the firewal so our next step is gonna be to turn it off and we'll see. As concerning the thread dump the thread you suppose is stuck is runnable (scheduled to run when it turn comes), same as ours. So it looks to me that it's stuck in the communication between apache and tomcat in your case (jdbc on tomcat to db in our case) Another thing I'm not sure about is, when we check the tcp sockets opened on both side on the db and the server with tomcat (netstat), the number doesn't match. We are running Redhat ES 4, tomcat 5.5.12, apache 2.0.52, jk_mod 1.2.15 and yes, we can not reproduce it on our testing/dev environment (without firewall), it appears only in pre-production. I'd like to add we are having these problems with both our own and jakarat's(DataSource) connection pooling. So this has been checked + no Exceptions in the logs. Any help, advice, idea greatly welcomed. Mirek On 12/9/05, Richard Mixon <[EMAIL PROTECTED]> wrote: > > >Can anyone take a look at the thread dump below and give me a clue as > >to what cause the CPU to rise to 99% and things to get unresponsive? > >Sorry > the > >dump is so large (850 lines) > > Oh ... This is a Fedora Core 2 Linux box with 1GB of RAM and dual Xeons. > Thanks -Richard > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
