DO NOT REPLY [Bug 45144] New: using JDBC Data Sources freezes tomcat for some minutes
https://issues.apache.org/bugzilla/show_bug.cgi?id=45144 Summary: using JDBC Data Sources freezes tomcat for some minutes Product: Tomcat 6 Version: 6.0.16 Platform: PC OS/Version: Linux Status: NEW Severity: blocker Priority: P2 Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Created an attachment (id=22083) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22083) the full jstack -l output Hi, about system: running on a IBM System x3200 (Xeon dual core) machine with CentOS Linux 2.6.18-53.1.19.el5 #1 SMP Wed May 7 08:22:53 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux /opt/java/jdk1.6.0_06/bin/java -server -version java version "1.6.0_06" Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) 64-Bit Server VM (build 10.0-b22, mixed mode) About the Problem: when getting new connection from the pool i'm getting many thread BLOCKED for 2 minutes, sometimes seconds, when this occurs today, i take a jstack from JVM and discover that the org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory is locked and many threads BLOCKED waiting to lock the same instance of PoolableConnectionFactory, follow i cut the most important part of the stack trace: The blocker part: "http-80-exec-18" daemon prio=10 tid=0x54387400 nid=0x442f runnable [0x43137000..0x43138c90] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at com.sap.dbtech.rte.comm.BasicSocketComm.receiveConnect(BasicSocketComm.java:707) at com.sap.dbtech.rte.comm.BasicSocketComm.dbConnectExchange(BasicSocketComm.java:789) at com.sap.dbtech.rte.comm.BasicSocketComm.connectDB(BasicSocketComm.java:233) at com.sap.dbtech.rte.comm.SocketComm$1.open(SocketComm.java:38) at com.sap.dbtech.jdbc.DriverSapDB.openConnection(DriverSapDB.java:966) at com.sap.dbtech.jdbc.DriverSapDB.openByURL(DriverSapDB.java:891) at com.sap.dbtech.jdbc.DriverSapDB.connect(DriverSapDB.java:208) - locked <0x2aaab74c6978> (a com.sap.dbtech.jdbc.DriverSapDB) at org.apache.tomcat.dbcp.dbcp.DriverConnectionFactory.createConnection(DriverConnectionFactory.java:38) at org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:294) - locked <0x2aaab74c6a18> (a org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory) at org.apache.tomcat.dbcp.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:974) at org.apache.tomcat.dbcp.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:96) at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880) at org.exolab.castor.jdo.engine.DatabaseRegistry.createConnection(DatabaseRegistry.java:399) at org.exolab.castor.jdo.engine.TransactionContextImpl.getConnection(TransactionContextImpl.java:203) at org.exolab.castor.persist.TransactionContext.query(TransactionContext.java:644) - locked <0x2aaafc1adb20> (a org.exolab.castor.jdo.engine.TransactionContextImpl) at org.exolab.castor.jdo.engine.OQLQueryImpl.execute(OQLQueryImpl.java:458) at org.exolab.castor.jdo.engine.OQLQueryImpl.execute(OQLQueryImpl.java:405) at com.supridatta.act.produtos.PedidoAction.onIncluir(PedidoAction.java:70) at com.supridatta.bean.DataPersist.gravar(DataPersist.java:213) ... Locked ownable synchronizers: - <0x2aaad0bfb648> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) The blocked part: "http-80-exec-43" daemon prio=10 tid=0x5356f000 nid=0x5619 waiting for monitor entry [0x44046000..0x44047c10] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:294) - waiting to lock <0x2aaab74c6a18> (a org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory) at org.apache.tomcat.dbcp.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:974) at org.apache.tomcat.dbcp.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:96) at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880) at org.exolab.castor.jdo.engine.DatabaseRegistry.createConnection(DatabaseRegistry.java:399) at org.exolab.castor.jdo.engine.TransactionContextImpl.getConnection(TransactionContextImpl.java:203) at org.exolab.castor.persist.TransactionContext.query(TransactionContext.java:644) - locked <0x2aaafd720be0> (a org.exolab.castor.jdo.engine.TransactionContextImpl) at org.exolab.castor.jdo.engine.OQLQueryImpl.execute(OQLQueryImpl.java:458) at org.exolab.castor.jdo.engine.OQLQuer
DO NOT REPLY [Bug 45144] using JDBC Data Sources freezes tomcat for some minutes
https://issues.apache.org/bugzilla/show_bug.cgi?id=45144 --- Comment #1 from Clóvis Wichoski <[EMAIL PROTECTED]> 2008-06-05 13:19:51 PST --- This is how the Resource is configured: -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43683] Accessing Servlet while Reloading context gives 404 error
https://issues.apache.org/bugzilla/show_bug.cgi?id=43683 --- Comment #10 from Joe Kislo <[EMAIL PROTECTED]> 2008-06-05 19:46:01 PST --- Well thanks for the compliment on the test cases... These issues are very important to us, so I'm *extremely* grateful you're spending time looking into them. But I'm sorry to report that my test case for this next one isn't as good :) So first, your fix with the classloader issues seems to have fixed up that problem. However, if I use the 2nd testcase, and do: ab -c 10 -n 60 http://localhost:8080/ServletRestartTest2/ServletRestartTest then reload the context: http://localhost:8080/ServletRestartTest2/ServletRestartTest I am still getting some non 200 requests: Complete requests: 60 Failed requests:11 (Connect: 0, Length: 11, Exceptions: 0) Write errors: 0 Non-2xx responses: 11 I swear I didn't this before... So maybe I'm crazy... But maybe I was distracted last time by trying to track down the classloader testcase. If I try to do the tests from my browser... they *usually* work just fine. But sometimes, I'll get the 404 in my browser too. I would just say it's a race condition as to when I reload the context, but can't quite put my finger on it. It seems like once it gets one 404... every time I try it after that (until I restart tomcat) it'll get the 404 on reload. *sigh* Sorry I can't be more helpful. Can you tell me if you are still seeing non-200s with the apache bench test? It seems like maybe you fixed one path where you can get a 404, but maybe there's another. It looks like requests that come in right after the destroy finishes, but before the init starts that are getting the 404s now. So I did find a *second* issue, which is also intermittent, and may have been introduced by your first fix (although I don't know). I've spent the past two days (well, a couple hours yesterday and a few hours today) trying to get a narrow testcase for you. I've got one, and I'll attach it as ServletRestartTest3. In your browser, you need to open Three tabs 1:http://localhost:8080/manager/reload?path=/ServletRestartTest3 2:http://localhost:8080/ServletRestartTest3/ServletRestartTest 3:http://localhost:8080/ServletRestartTest3/ServletRestartTest You need to start tomcat, then reload tab 2, then 1, then 3 This is what happens (sometimes!) the servlet will init() then the servlet will destroy() but while the destroy is running, it will service the request for tab 2 on the same servlet the destroy() will finish the servlet will init() the servlet will service tab 3. Unfortunately, what it's doing is serving a request (tab #2) *while* it's in the middle of destroying the context. Bad bad bad :( In the testcase I have rigged up it will cause a nullpointer exception in tab #2 when that happens: java.lang.NullPointerException ServletRestartTest.doGet(ServletRestartTest.java:43) javax.servlet.http.HttpServlet.service(HttpServlet.java:617) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) You'll see this on your tomcat console: init starting [GC [DefNew: 960K->64K(960K), 0.0029550 secs] 4176K->3426K(5056K), 0.0029980 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] Jun 5, 2008 10:13:07 PM org.apache.catalina.core.StandardContext reload INFO: Reloading this Context has started init completed destroy starting starting servicing destroy completed [GC [DefNew: 960K->64K(960K), 0.0034250 secs] 4322K->3539K(5056K), 0.0034690 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC [DefNew: 960K->64K(960K), 0.0019920 secs] 4435K->3623K(5056K), 0.0020690 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] init starting init completed starting servicing servicing completed If you can't get it to happen first try, reload tab #1, which will shutdown the context... Then do tab #2, #1, #3. It may take you a few times to get it to happen. It's intermittent :( You'll see that Testcase #3 has a very tight loop at the init(). I tried a sleep(5000), and it was *significantly* more difficult to get the problem to happen. With the 5 second tight loop, it's much easier (although still not consistent). Let me know if there's anything I can do to help -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43683] Accessing Servlet while Reloading context gives 404 error
https://issues.apache.org/bugzilla/show_bug.cgi?id=43683 --- Comment #11 from Joe Kislo <[EMAIL PROTECTED]> 2008-06-05 19:47:16 PST --- Created an attachment (id=22084) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22084) Testcase 3 - ServletRestartTest.war -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
