Hi Thomas, Were you able to resolve you problem yet. Could you post the solution if yes, please? thanks a lot, Mirek
On 12/7/05, Mirek Kopriva <[EMAIL PROTECTED]> wrote: > > 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] > > > > >
