Well, We were using our own connection pool and first thing, which came into my mind was exactly this. So we changed it to tomcat's connection pooling (DataSource in JNDI) and the result was the same bad. Besides, in the jvm stack trace (I missplaced it, but I will send here a new one when I have a little more time and when the app. gets into the bad state again), I can see that it gets stuck when trying to call setAutocommit on the OraceConnection object, which is locked. And I can't see any other thread locking the object. Of course I'm not 100% sure I read the stack dump correctly, or the thread dump is correct but it seems it's like that.
Besides we have a timeout set on getting the Connection (not more than a minute), so if the problem would be there we wouldn't be waiting for 20 minutes. So it reaally looks like threads being stucked. At the moment I read somewhere that running the tomcat as daemon should fix the issue, so we are trying that. If this fails we will try to disable the firewall between the tomcat and the database but it's really just catching at straws. Regards, Mirek On 12/7/05, Konrath Thomas <[EMAIL PROTECTED]> wrote: > > Hi ... > > Thanks for your hint, but I think this also didn't work for us ... > > You wrote like there could be a problem with the jdbc driver. > Could you explain that in more detail? > > Do you use a connection pool? If yes, which one? > > Currently, we are using a connection pool which has been made from us > long time ago which uses the jdbc-thin connections to the database. We > are think about to change to the Oracle connection pool or to the Tomcat > connection pool. > > > Kind Regards > Thomas Konrath > > > > -----Ursprüngliche Nachricht----- > Von: Mirek Kopriva [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 06. Dezember 2005 20:24 > An: Tomcat Users List > Betreff: Re: Critical problem with Tomcat worker threads > > > Hi, > We are experiencing similar problem. Just the Thread gets stuck for > random period time (between 1 and 15 minutes) after also random period > of time. For some reason its always in jdbc driver. Typicaly on the > pre-production environment, never on test, developement machines. We are > using mod_jk, tomcat 5.5.12 and jdk 5.0_b5. RedHat ES 4. > > Anyway try this thread and let us know when you fix your problem. Didn't > work for us though. > > http://forum.java.sun.com/thread.jspa?threadID=580350 > Regards, > mk > > On 12/6/05, Konrath Thomas <[EMAIL PROTECTED]> wrote: > > > > Hi . > > > > > > > > We have a strange problem with out Tomcat server. Sometime (and really > > > just sometimes) Tomcat opens a lot of threads until the maximum number > > > of Tomcat worker processes is reached and the users cannot do > > anything. > > > > > > > > We have made a Java Stack Dump to get a clue, what is going on in the > > threads. > > > > > > > > After a short analyse of several stack dumps I encountered the > > following > > behaviour: > > > > > > > > When a thread has finished his request from the user it seems that he > > is going back to the state, where he waits for the next user request > > (see stack dump below). > > > > 1. java.net.SocketInputStream:socketRead0 > > 2. java.net.SocketInputStream:read(SocketInputStream.java:129) > > 3. java.io.BufferedInputStream:fill(BufferedInputStream.java:183) > > 4. > java.io.BufferedInputStream:read1(BufferedInputStream.java:222) > > 5. java.io.BufferedInputStream:read(BufferedInputStream.java:277) > > 6. locked-->java.io.BufferedInputStream(0x5773e070) > > 7. > org.apache.jk.common.ChannelSocket:read(ChannelSocket.java:598) > > 8. > > org.apache.jk.common.ChannelSocket:receive(ChannelSocket.java:535) > > 9. > > org.apache.jk.common.ChannelSocket:processConnection(ChannelSocket.jav > > a: > > 663) > > 10. > > org.apache.jk.common.SocketConnection:runIt(ChannelSocket.java:866) > > 11. > > > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable:run(ThreadPool > > .java:683) > > 12. java.lang.Thread:run(Thread.java:534) > > > > Question: What does this "locked" mean? Is this thread really locked > > or is he just waiting for something? If he is locked, why? > > > > > > > > The thread remains there e very long time, although we are sure, that > > there are some user request's waiting to process at the server. > > > > After some time the thread comes to another state, which seems to me > > like a clean up from the Tomcat server (see stack dump below) > > > > > > > > 1. java.lang.Object:wait > > 2. waiting > > on-->org.apache.tomcat.util.threads.ThreadPool$ControlRunnable(0x52a4d > > on-->94 > > 0) > > 3. java.lang.Object:wait(Object.java:429) > > 4. > > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable:run(ThreadPo > > ol > > .java:655) > > 5. > > locked-->org.apache.tomcat.util.threads.ThreadPool$ControlRunnable(0x5 > > locked-->2a > > 4d940) > > 6. java.lang.Thread:run(Thread.java:534) > > > > > > > > We have configured our Tomcat to remove worker threads after 60 > > seconds idle time. > > > > > > > > Question: Is this correct? > > > > > > > > > > > > We use an Apache server and use a mod_jk 2 / AJP module do forward the > > > user requests to the Tomcat server and returning the response > > (configuration in the server.xml listed below). > > > > > > > > <!-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 --> > > > > <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" > > > > port="8017" minProcessors="5" maxProcessors="100" > > > > enableLookups="false" redirectPort="8443" > > > > acceptCount="10" debug="0" connectionTimeout="60000" > > > > useURIValidationHack="false" > > > > > > protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/> > > > > > > > > > > > > > > > > Question: > > > > Could it be that the Apache or Tomcat doesn't clean up the connections > > > between them so that they cannot reuse a connection? > > > > Does anyone have encountered a similar problem? > > > > How can I solve this problem? > > > > > > > > > > > > We use: > > > > Apache 2 > > > > Jakarta Tomcat 4.1.31 > > j2sdk 1.4.2_06 > > Suse Linux Enterprise Server 8 > > > > > > > > > > > > Thanks for any help, > > > > > > > > kind regards > > > > > > > > DI(FH) Thomas Konrath > > > > unycom IT Services GmbH > > > > Solutions > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
