Print parameters in Tomcat JDBC Pool's SlowQueryReport
Hi, I recently have started using the SlowQueryReport to tackle performance issues. The log message, unfortunately, does not contain the parameters passed to the prepared statements. Though AbstractQueryReport receives this information in protected String report*Query(String query, Object[] args, final String name, long start, long delta) but ignores this information. The report would highly benefit from. E.g., Commons DBUtils prints out the query and the parameters in the case of an exception. The sole query isn't really helpful. Can we add this? Should I file a ticket? Thanks, Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 5/8/13 3:01 AM, Michael-O wrote: I recently have started using the SlowQueryReport to tackle performance issues. The log message, unfortunately, does not contain the parameters passed to the prepared statements. Though AbstractQueryReport receives this information in protected String report*Query(String query, Object[] args, final String name, long start, long delta) but ignores this information. The report would highly benefit from. E.g., Commons DBUtils prints out the query and the parameters in the case of an exception. The sole query isn't really helpful. Can we add this? Sure. Should I file a ticket? Yes. A BZ issue with a patch is likely to get done a whole lot faster than one without a patch (plus you get credit for your contribution). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRijzdAAoJEBzwKT+lPKRYIwkP/jqRuNAegMYMBKXm33KqjblZ U8k4JMGM4sCGBjcZjoyawN0u0MF2mRSdznxnDxghtmoc8byoxraNLiZ4p3DHvJv3 XC8/DATQEyVj2CaWAcSNqZq5uN3+jjx+2faa7G6hq1VJ8dfaA0ljcD9cfruGXxv+ OEFeMsWsY8IxR3JclQAsgRp05mCD9FN215pGDlwUdGn6l4dSPYFiEMGTW1b4QSFx ga8TFi7XKfbzT3Rn0NdTh4qUQzprk/4C8tTlcVRvycHm16zrW8tnUZ5RGn80REaB yGPScZkKLD5F1rCS5jUg7Ylyz1eTvi31iY7EdoMF1uVY7lpMpsymRPUwyhVbIoW3 5UUBcphnL4MW0IeDq6NfdwKVKPuG5frpuZc65ppeW/GEdPEi2mMwFw8gXA8X+kkj AOsoPCBpdLxyXsyDaFKFf8QnADwBIgQ2srCqLAwRNvPwNpAFtRcaeymAWN6xcst9 tWucgYWLRFKTNcwigMw4c2bBtnNiPJXx0utBcOZZWZZPonc9jyASN/SpIJd6Pb05 lrpl0uxjlWcJy7o/p+2pKE8q6jjBaqQgBH7oijMNUZDsfv2mDLIbiKk/IUvRTg6a g0qysIUwubRSjdwOlFigkdStsGKj3ned9wbpcu12RFhMhJx2Aan4dHa1rNS6q7Vb kIMv6VXcgiY/NUMKlj39 =r0L4 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport
On May 8, 2013, at 6:54 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 5/8/13 3:01 AM, Michael-O wrote: I recently have started using the SlowQueryReport to tackle performance issues. The log message, unfortunately, does not contain the parameters passed to the prepared statements. Though AbstractQueryReport receives this information in protected String report*Query(String query, Object[] args, final String name, long start, long delta) but ignores this information. The report would highly benefit from. E.g., Commons DBUtils prints out the query and the parameters in the case of an exception. The sole query isn't really helpful. Can we add this? Sure. Should I file a ticket? Yes. A BZ issue with a patch is likely to get done a whole lot faster than one without a patch (plus you get credit for your contribution). - -chris There needs to be an option to disable logging query parameters somehow. Query parameters are sometimes sensitive, and in some environments (medical, legal, etc.) logging them might even be in violation of the law. Nick smime.p7s Description: S/MIME cryptographic signature
Tomcat thread dump analysis
Hi, We have a weird issue on our site which some random trigger event will backup all c3p0 connections until it hits the max pool size. I have scripts that will do a softReset on the c3p0 connection pool when they hit their max so help us manage the issue and to also help me have time to hopefully get some decent thread dumps to catch the underlying issue. The problem happened yesterday and I get a lot of these: TP-Processor396 daemon prio=10 tid=0x2aff2ba9d000 nid=0x5a7b waiting on condition [0x2aff61e98000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x2afecfb91da0 (a java.util.concurrent.Semaphore$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281) at java.util.concurrent.Semaphore.acquire(Semaphore.java:286) at com.tc.object.locks.LockStateNode$PendingLockHold.park(LockStateNode.java:179) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:723) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:701) at com.tc.object.locks.ClientLockImpl.lock(ClientLockImpl.java:52) at com.tc.object.locks.ClientLockManagerImpl.lock(ClientLockManagerImpl.java:98) at com.tc.object.bytecode.ManagerImpl.lock(ManagerImpl.java:747) If I look at a stack before the issue happened, I see no TP-Processor threads with the parking to wait for. What can i read into this? Thanks, Charles
Re: Tomcat thread dump analysis
Oh and sorry, we are using Tomcat 6.0.30 . Cheers! On Wed, May 8, 2013 at 9:20 AM, Charles Richard charle...@thelearningbar.com wrote: Hi, We have a weird issue on our site which some random trigger event will backup all c3p0 connections until it hits the max pool size. I have scripts that will do a softReset on the c3p0 connection pool when they hit their max so help us manage the issue and to also help me have time to hopefully get some decent thread dumps to catch the underlying issue. The problem happened yesterday and I get a lot of these: TP-Processor396 daemon prio=10 tid=0x2aff2ba9d000 nid=0x5a7b waiting on condition [0x2aff61e98000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x2afecfb91da0 (a java.util.concurrent.Semaphore$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281) at java.util.concurrent.Semaphore.acquire(Semaphore.java:286) at com.tc.object.locks.LockStateNode$PendingLockHold.park(LockStateNode.java:179) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:723) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:701) at com.tc.object.locks.ClientLockImpl.lock(ClientLockImpl.java:52) at com.tc.object.locks.ClientLockManagerImpl.lock(ClientLockManagerImpl.java:98) at com.tc.object.bytecode.ManagerImpl.lock(ManagerImpl.java:747) If I look at a stack before the issue happened, I see no TP-Processor threads with the parking to wait for. What can i read into this? Thanks, Charles
Re: Tomcat thread dump analysis
On May 8, 2013, at 8:20 AM, Charles Richard wrote: Hi, We have a weird issue on our site which some random trigger event will backup all c3p0 connections until it hits the max pool size. I have scripts that will do a softReset on the c3p0 connection pool when they hit their max so help us manage the issue and to also help me have time to hopefully get some decent thread dumps to catch the underlying issue. The problem happened yesterday and I get a lot of these: TP-Processor396 daemon prio=10 tid=0x2aff2ba9d000 nid=0x5a7b waiting on condition [0x2aff61e98000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x2afecfb91da0 (a java.util.concurrent.Semaphore$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281) at java.util.concurrent.Semaphore.acquire(Semaphore.java:286) at com.tc.object.locks.LockStateNode$PendingLockHold.park(LockStateNode.java:179) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:723) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:701) at com.tc.object.locks.ClientLockImpl.lock(ClientLockImpl.java:52) at com.tc.object.locks.ClientLockManagerImpl.lock(ClientLockManagerImpl.java:98) at com.tc.object.bytecode.ManagerImpl.lock(ManagerImpl.java:747) What in your application is using the com.tc.object.locks package? This is not used by Tomcat. Dan If I look at a stack before the issue happened, I see no TP-Processor threads with the parking to wait for. What can i read into this? Thanks, Charles - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat thread dump analysis
We are using Terracotta which is a bit of a black box to me (setup I've inherited). Terracotta helps us with the Tomcat sessions being transportable across front end servers. Cheers! Charles On Wed, May 8, 2013 at 9:27 AM, Daniel Mikusa dmik...@gopivotal.com wrote: On May 8, 2013, at 8:20 AM, Charles Richard wrote: Hi, We have a weird issue on our site which some random trigger event will backup all c3p0 connections until it hits the max pool size. I have scripts that will do a softReset on the c3p0 connection pool when they hit their max so help us manage the issue and to also help me have time to hopefully get some decent thread dumps to catch the underlying issue. The problem happened yesterday and I get a lot of these: TP-Processor396 daemon prio=10 tid=0x2aff2ba9d000 nid=0x5a7b waiting on condition [0x2aff61e98000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x2afecfb91da0 (a java.util.concurrent.Semaphore$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281) at java.util.concurrent.Semaphore.acquire(Semaphore.java:286) at com.tc.object.locks.LockStateNode$PendingLockHold.park(LockStateNode.java:179) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:723) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:701) at com.tc.object.locks.ClientLockImpl.lock(ClientLockImpl.java:52) at com.tc.object.locks.ClientLockManagerImpl.lock(ClientLockManagerImpl.java:98) at com.tc.object.bytecode.ManagerImpl.lock(ManagerImpl.java:747) What in your application is using the com.tc.object.locks package? This is not used by Tomcat. Dan If I look at a stack before the issue happened, I see no TP-Processor threads with the parking to wait for. What can i read into this? Thanks, Charles - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/8/13 8:08 AM, Nick Williams wrote: On May 8, 2013, at 6:54 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 5/8/13 3:01 AM, Michael-O wrote: I recently have started using the SlowQueryReport to tackle performance issues. The log message, unfortunately, does not contain the parameters passed to the prepared statements. Though AbstractQueryReport receives this information in protected String report*Query(String query, Object[] args, final String name, long start, long delta) but ignores this information. The report would highly benefit from. E.g., Commons DBUtils prints out the query and the parameters in the case of an exception. The sole query isn't really helpful. Can we add this? Sure. Should I file a ticket? Yes. A BZ issue with a patch is likely to get done a whole lot faster than one without a patch (plus you get credit for your contribution). - -chris There needs to be an option to disable logging query parameters somehow. Query parameters are sometimes sensitive, and in some environments (medical, legal, etc.) logging them might even be in violation of the law. +1 If you really want to get cute, allow the user to specify named query parameters that should never be displayed e.g. 'password', though this is a) perhaps not possible and b) not reliable because you can bind parameters by position as well as by name. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRikdbAAoJEBzwKT+lPKRY78UP/RwHLoAjziifH691fQu5NySU 5TeDj0MMeNGzNy4+4ov6Rclhd48XySKYdyecxsqQERM4FLo/e4R/E6BHdURgNSjA hcfcRk1t6wGiRLn3wykQxNMBWI7JpWN/oUOcVSnXhi3G7xZKAIJfMqVwO2NkoQw2 GBhjKOD4zGRG17CFWD16jG0akm3LttL4OsjuWiRD5UqkkWkkg9JKJKfe6WRSDLnl 2OYw245UCcC37r79gFHZikvVTlu29mbU80tNj0BEK/PlZjzmnfV5gIZCU3kO7njj 0iT3hTrZ3Y1KOEyptyYEdgHDqVxRf02P3y1brDZmq3au7RiZhBwIMQDHqPB7dXaQ SDqcUHCrNxgKc/O2ydKX+kgbzLE5cCXGzSWK+UMnjxXqekg/utmss5z48P16UJPh EAyy5GC4C2M1htpYegFba4o3HvWlu0GnM7W0G+dwzZxrREWwfZCs9ggn4lxd36MS +rEwBtNsATGalfBy//XGJsXJNgUNuGPsD5bT9Yl1QvNidI8yxa91C1X4sz0wYgXY 3+aA++7hDCb8kvkkGqfJiznD8CQVIsZv7RMzCanlE/3ilBPFslJGnVtC/WggFCJx HQFqeOPnikRaZMqC0n4XTiM1n2sLuKnI+Fki2j+euPdwa5gDxydE+H4eL5WG/6qe 6mE49gaMqyRXugIeO2W1 =ZISZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat thread dump analysis
Just saw this which I believe describes exactly what is happening: http://forums.terracotta.org/forums/posts/list/6470.page We are using Spring as well. Trying to understand the solution: Charles On Wed, May 8, 2013 at 9:31 AM, Charles Richard charle...@thelearningbar.com wrote: We are using Terracotta which is a bit of a black box to me (setup I've inherited). Terracotta helps us with the Tomcat sessions being transportable across front end servers. Cheers! Charles On Wed, May 8, 2013 at 9:27 AM, Daniel Mikusa dmik...@gopivotal.comwrote: On May 8, 2013, at 8:20 AM, Charles Richard wrote: Hi, We have a weird issue on our site which some random trigger event will backup all c3p0 connections until it hits the max pool size. I have scripts that will do a softReset on the c3p0 connection pool when they hit their max so help us manage the issue and to also help me have time to hopefully get some decent thread dumps to catch the underlying issue. The problem happened yesterday and I get a lot of these: TP-Processor396 daemon prio=10 tid=0x2aff2ba9d000 nid=0x5a7b waiting on condition [0x2aff61e98000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x2afecfb91da0 (a java.util.concurrent.Semaphore$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281) at java.util.concurrent.Semaphore.acquire(Semaphore.java:286) at com.tc.object.locks.LockStateNode$PendingLockHold.park(LockStateNode.java:179) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:723) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:701) at com.tc.object.locks.ClientLockImpl.lock(ClientLockImpl.java:52) at com.tc.object.locks.ClientLockManagerImpl.lock(ClientLockManagerImpl.java:98) at com.tc.object.bytecode.ManagerImpl.lock(ManagerImpl.java:747) What in your application is using the com.tc.object.locks package? This is not used by Tomcat. Dan If I look at a stack before the issue happened, I see no TP-Processor threads with the parking to wait for. What can i read into this? Thanks, Charles - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat thread dump analysis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles, On 5/8/13 8:31 AM, Charles Richard wrote: On Wed, May 8, 2013 at 9:27 AM, Daniel Mikusa dmik...@gopivotal.com wrote: On May 8, 2013, at 8:20 AM, Charles Richard wrote: Hi, We have a weird issue on our site which some random trigger event will backup all c3p0 connections until it hits the max pool size. I have scripts that will do a softReset on the c3p0 connection pool when they hit their max so help us manage the issue and to also help me have time to hopefully get some decent thread dumps to catch the underlying issue. The problem happened yesterday and I get a lot of these: TP-Processor396 daemon prio=10 tid=0x2aff2ba9d000 nid=0x5a7b waiting on condition [0x2aff61e98000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x2afecfb91da0 (a java.util.concurrent.Semaphore$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281) at java.util.concurrent.Semaphore.acquire(Semaphore.java:286) at com.tc.object.locks.LockStateNode$PendingLockHold.park(LockStateNode.java:179) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:723) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:701) at com.tc.object.locks.ClientLockImpl.lock(ClientLockImpl.java:52) at com.tc.object.locks.ClientLockManagerImpl.lock(ClientLockManagerImpl.java:98) at com.tc.object.bytecode.ManagerImpl.lock(ManagerImpl.java:747) If I look at a stack before the issue happened, I see no TP-Processor threads with the parking to wait for. What can i read into this? What in your application is using the com.tc.object.locks package? This is not used by Tomcat. We are using Terracotta which is a bit of a black box to me (setup I've inherited). Terracotta helps us with the Tomcat sessions being transportable across front end servers. Please don't top-post: it's confusing and hard to follow. Unfortunately, I don't see any Tomcat code in here anywhere, so I can't really help (yet). Is that the whole stack trace? I find it difficult to believe there bytecode.ManagerImpl is a Runnable or extends Thread, especially because the run method isn't the lowest in the stack trace. Can you give us more information? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRikhNAAoJEBzwKT+lPKRY53QP/1oz2eR+CRG+g/+2Oedh1UjE FckiVRQFkLsFSJBelGdQU+x0wBljgiSiOUgVaEQotpnaLO8pQCFmjMPcCsAZ2YiY xmnfHf2s89w/YGXo7HNB5X1okhpn+1pzjznmUvHGLGKO5+OUTdJvZ2stS6m6uEfg Vtmn6IQZywUyLKOcZ/Tl/UESirYjIaT5ky3Mvxbb/9JAyXICutJtxZQdZDG7U1du UU7BwmMQP/7ZiCiR9zUoarr2MT5FTgy1mpBGGI0OopmZilvo83UiyBcJJ/lN5miz PlE0BqisOeZIk5hAX+FqUZ1rTFvjpPNQjfN/9TRelhOs9fP9ZaTQ4PIkjwP8h2R7 V2aqQmIrrZSrjS2SRsPx+iEnd6klwGpvlPoCyuWhikjKdv06nwZ7iDLWePw9lek7 x8q6KeuE5KUy5w0EGN23zx54sh92eipjXj1uBBWBoA8cA6DZEXEPG+cGGoj/cR9+ 9mhdOUbKSd9MQUR4H1b2+sErTZhj1KeBPxnBxeUU7FVoIn7J/x+DMXtYMU5OX6Kq jO0YTAXUMGAb6WPR2pz5bU2nvlev8JVVDwtjmV6l3P+czAqVQ7aUDc6aRfPbcM+D RJb4i64Ww41ZgbJv4YQ5SkxgdLIcjlzMu07pPXUwonlQI8NGvZsMN60eeKXnrrX5 tnst+5jt/p/7mSULqAtR =ATll -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
backslash URL encoding
Dear Users, Tomcat 7.0.39. I have problem with the following url in firefox 20: http://dictzone.com/english-german-dictionary/a\ (it resulted in the http://dictzone.com/english-german-dictionary/a%5C request). It results is an emtpy page. This request don't arrive my servelt / filter codes. How to fix it? Regards, Ferenc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat thread dump analysis
On May 8, 2013, at 8:39 AM, Charles Richard wrote: Just saw this which I believe describes exactly what is happening: http://forums.terracotta.org/forums/posts/list/6470.page We are using Spring as well. Trying to understand the solution: If this is the problem that you're experiencing it does not seem to be related to Tomcat. You might be better off posting on the Terracotta or Spring forum, depending on the exact problem. Dan Charles On Wed, May 8, 2013 at 9:31 AM, Charles Richard charle...@thelearningbar.com wrote: We are using Terracotta which is a bit of a black box to me (setup I've inherited). Terracotta helps us with the Tomcat sessions being transportable across front end servers. Cheers! Charles On Wed, May 8, 2013 at 9:27 AM, Daniel Mikusa dmik...@gopivotal.comwrote: On May 8, 2013, at 8:20 AM, Charles Richard wrote: Hi, We have a weird issue on our site which some random trigger event will backup all c3p0 connections until it hits the max pool size. I have scripts that will do a softReset on the c3p0 connection pool when they hit their max so help us manage the issue and to also help me have time to hopefully get some decent thread dumps to catch the underlying issue. The problem happened yesterday and I get a lot of these: TP-Processor396 daemon prio=10 tid=0x2aff2ba9d000 nid=0x5a7b waiting on condition [0x2aff61e98000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x2afecfb91da0 (a java.util.concurrent.Semaphore$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281) at java.util.concurrent.Semaphore.acquire(Semaphore.java:286) at com.tc.object.locks.LockStateNode$PendingLockHold.park(LockStateNode.java:179) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:723) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:701) at com.tc.object.locks.ClientLockImpl.lock(ClientLockImpl.java:52) at com.tc.object.locks.ClientLockManagerImpl.lock(ClientLockManagerImpl.java:98) at com.tc.object.bytecode.ManagerImpl.lock(ManagerImpl.java:747) What in your application is using the com.tc.object.locks package? This is not used by Tomcat. Dan If I look at a stack before the issue happened, I see no TP-Processor threads with the parking to wait for. What can i read into this? Thanks, Charles - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: backslash URL encoding
On May 8, 2013, at 8:46 AM, Lutischán Ferenc wrote: Dear Users, Tomcat 7.0.39. I have problem with the following url in firefox 20: http://dictzone.com/english-german-dictionary/a\ (it resulted in the http://dictzone.com/english-german-dictionary/a%5C request). Why do you have a \ on the end of the URL? Is that intentional? Does it work if you remove it? It results is an emtpy page. What is the HTTP Status code being returned with the request? 4xx? 5xx? This request don't arrive my servelt / filter codes. Please include your servlet mapping from web.xml. Dan How to fix it? Regards, Ferenc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat JDBC with PostgreSQL
Dear Users, Tomcat 7.0.39. I have the following configuration in META-INF/context.xml: ?xml version=1.0 encoding=UTF-8? Context cookies=false path=/ reloadable=true Resource name=jdbc/template auth=Container driverClassName=org.postgresql.Driver factory=org.apache.tomcat.jdbc.pool.DataSourceFactory initialSize=2 maxIdle=20 maxActive=20 maxWait=5000 password= type=javax.sql.DataSource url=jdbc:postgresql://x.x.x.x/x username=template validationQuery=select 1 jdbcInterceptors=ConnectionState;SlowQueryReportJmx(threshold=1000)/ /Context The situation: - The database side the connection closed - The tomcat pool don't renew the connection How to fix it? Regards, Ferenc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat JDBC with PostgreSQL
On May 8, 2013, at 8:54 AM, Lutischán Ferenc wrote: Dear Users, Tomcat 7.0.39. I have the following configuration in META-INF/context.xml: ?xml version=1.0 encoding=UTF-8? Context cookies=false path=/ reloadable=true Resource name=jdbc/template auth=Container driverClassName=org.postgresql.Driver factory=org.apache.tomcat.jdbc.pool.DataSourceFactory initialSize=2 maxIdle=20 maxActive=20 maxWait=5000 password= type=javax.sql.DataSource url=jdbc:postgresql://x.x.x.x/x username=template validationQuery=select 1 jdbcInterceptors=ConnectionState;SlowQueryReportJmx(threshold=1000)/ /Context The situation: - The database side the connection closed - The tomcat pool don't renew the connection Try setting testOnBorrow to true. With the Tomcat JDBC connection pool the testOn* properties default to false, which is different than the defaults for DBCP. Dan How to fix it? Regards, Ferenc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: backslash URL encoding
Dear Dan, Thank for your reply. 1. This site is a dictionary: - Windows users often enter a \ in place of / - Rarely there are \ in the phrases 2. The returned status code is: 400 Bad Request 3. Mappings: servlet servlet-nameindex/servlet-name servlet-classcom.ys.dictzone.Index/servlet-class /servlet servlet-mapping servlet-nameindex/servlet-name url-pattern/*/url-pattern /servlet-mapping servlet-mapping servlet-nameerror404/servlet-name url-pattern/error404/url-pattern /servlet-mapping servlet-mapping servlet-nameerror500/servlet-name url-pattern/error500/url-pattern /servlet-mapping filter filter-nameSimpleCachingHeadersPageCachingFilter/filter-name filter-classcom.ys.cache.GzipCachingFilter/filter-class init-param param-namesuppressStackTrace/param-name param-valuefalse/param-value /init-param /filter filter-mapping filter-nameSimpleCachingHeadersPageCachingFilter/filter-name url-pattern/*/url-pattern /filter-mapping Regards, Ferenc 2013.05.08. 14:53 keltezéssel, Daniel Mikusa írta: On May 8, 2013, at 8:46 AM, Lutischán Ferenc wrote: Dear Users, Tomcat 7.0.39. I have problem with the following url in firefox 20: http://dictzone.com/english-german-dictionary/a\ (it resulted in the http://dictzone.com/english-german-dictionary/a%5C request). Why do you have a \ on the end of the URL? Is that intentional? Does it work if you remove it? It results is an emtpy page. What is the HTTP Status code being returned with the request? 4xx? 5xx? This request don't arrive my servelt / filter codes. Please include your servlet mapping from web.xml. Dan How to fix it? Regards, Ferenc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat JDBC with PostgreSQL
Thanks Dan, I would like to test it more, but I think it works. 2013.05.08. 15:01 keltezéssel, Daniel Mikusa írta: On May 8, 2013, at 8:54 AM, Lutischán Ferenc wrote: Dear Users, Tomcat 7.0.39. I have the following configuration in META-INF/context.xml: ?xml version=1.0 encoding=UTF-8? Context cookies=false path=/ reloadable=true Resource name=jdbc/template auth=Container driverClassName=org.postgresql.Driver factory=org.apache.tomcat.jdbc.pool.DataSourceFactory initialSize=2 maxIdle=20 maxActive=20 maxWait=5000 password= type=javax.sql.DataSource url=jdbc:postgresql://x.x.x.x/x username=template validationQuery=select 1 jdbcInterceptors=ConnectionState;SlowQueryReportJmx(threshold=1000)/ /Context The situation: - The database side the connection closed - The tomcat pool don't renew the connection Try setting testOnBorrow to true. With the Tomcat JDBC connection pool the testOn* properties default to false, which is different than the defaults for DBCP. Dan How to fix it? Regards, Ferenc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: backslash URL encoding
On May 8, 2013, at 9:09 AM, Lutischán Ferenc wrote: Dear Dan, Thank for your reply. 1. This site is a dictionary: - Windows users often enter a \ in place of / - Rarely there are \ in the phrases I think what you're looking for is this… org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security If you set it to true, it should allow '%2F' and '%5C' in your URL. This has security implications though. Please read the following link for CVE-2007-0450. https://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10 Dan 2. The returned status code is: 400 Bad Request 3. Mappings: servlet servlet-nameindex/servlet-name servlet-classcom.ys.dictzone.Index/servlet-class /servlet servlet-mapping servlet-nameindex/servlet-name url-pattern/*/url-pattern /servlet-mapping servlet-mapping servlet-nameerror404/servlet-name url-pattern/error404/url-pattern /servlet-mapping servlet-mapping servlet-nameerror500/servlet-name url-pattern/error500/url-pattern /servlet-mapping filter filter-nameSimpleCachingHeadersPageCachingFilter/filter-name filter-classcom.ys.cache.GzipCachingFilter/filter-class init-param param-namesuppressStackTrace/param-name param-valuefalse/param-value /init-param /filter filter-mapping filter-nameSimpleCachingHeadersPageCachingFilter/filter-name url-pattern/*/url-pattern /filter-mapping Regards, Ferenc 2013.05.08. 14:53 keltezéssel, Daniel Mikusa írta: On May 8, 2013, at 8:46 AM, Lutischán Ferenc wrote: Dear Users, Tomcat 7.0.39. I have problem with the following url in firefox 20: http://dictzone.com/english-german-dictionary/a\ (it resulted in the http://dictzone.com/english-german-dictionary/a%5C request). Why do you have a \ on the end of the URL? Is that intentional? Does it work if you remove it? It results is an emtpy page. What is the HTTP Status code being returned with the request? 4xx? 5xx? This request don't arrive my servelt / filter codes. Please include your servlet mapping from web.xml. Dan How to fix it? Regards, Ferenc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
On Tue, May 07, 2013 at 01:17:40PM -0400, Jesse Barnum wrote:
On May 7, 2013, at 9:40 AM, Mark H. Wood mw...@iupui.edu wrote:
Well, the developer can simply pack into the app. whatever internal
configuration is needed, since he has ready access to the interior of
the app and can deposit on the classpath *.properties, *.xml, or
anything else he wants. He can have no certain knowledge of the app's
runtime environment and should not assume, only specify requirements,
and provide sensible defaults when there are some.
The deployer, OTOH, has ready access to the app's environment,
including its Context, but should not be assumed to have such access
to the interior of the app.
So this division of labor depends on the developer's discipline in
distinguishing internal vs. external configuration and coding the
app. to look in the proper place for each. I don't see a good way for
the container to make up for incorrect design in this area.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Machines should not be friendly. Machines should be obedient.
Mark, can you give me an example of a use case where it is useful for the
deployer to modify parameter values in the META-INF/context.xml file? Assume
that at some point, a new version of the application will be deployed, and
also assume that the deployer does not wish to re-apply the same
customizations with each release.
Well, not really. My point was that things the deployer will want to
modify should not be in META-INF/context.xml; they should be in
${CATALINA_BASE}/conf/[enginename]/[hostname]/[appname].xml where they
are easy for the deployer to get at without digging in the
app. itself. I can't think of anything I would want to put in
META-INF/context.xml, really. The developer doesn't need that layer
of mapping; he knows where all the internal bits are and what they are
called, because he decrees them.
Keeping the Context descriptor outside of the app. means that it won't
be replaced when you deploy a new release (provided that you don't put
the app. in appBase). That's why I do it.
Without getting into the pros and cons of your first paragraph (which places
all responsibility for managing app preferences on the developer), would you
agree that the current approach (leaving the context.xml file in the web app)
is not fulfilling one of its intended purposes, which is allowing the
deployer to customize the application behavior?
I would. I suspect that what people had in mind was that some
installer program would automagically customize META-INF/context.xml,
so that the app. actually deployed is not quite the app. which is
shipped. I happen to think that 'tar', 'unzip', and 'cp' are the
three best installers out there, and would rather put my per-instance
settings somewhere outside the app. altogether. I very much
appreciate the way that Tomcat makes that possible.
I'm not sure what you mean by places all responsibilities for
managing app preferences on the developer. I thought that this
division requires that the developer *not* manage preferences, which I
take to be deployment details such as where's my database? or
what's the name of this business? Those are the responsibility of
the deployer; the developer is responsible for supplying values which
are invariant across instances, but which might be convenient to
gather into a .properties or some such.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
On Tue, May 07, 2013 at 04:45:39PM +, Jeffrey Janner wrote:
-Original Message-
From: Mark H. Wood [mailto:mw...@iupui.edu]
Sent: Tuesday, May 07, 2013 8:41 AM
To: users@tomcat.apache.org
Subject: Re: Why is context.xml no longer copied to
Catalina/localhost/myapp.xml?
On Mon, May 06, 2013 at 04:35:19PM -0400, Jesse Barnum wrote:
[snip]
I am sure that this would be out of scope, but if we pictured an
ideal scenario, it seems like there would be one configuration file
that is tightly managed by the developer, which is replaced when the
app is redeployed, and a different configuration file that is intended
for end user customization, which is stored separately.
Well, the developer can simply pack into the app. whatever internal
configuration is needed, since he has ready access to the interior of
the app and can deposit on the classpath *.properties, *.xml, or
anything else he wants. He can have no certain knowledge of the app's
runtime environment and should not assume, only specify requirements,
and provide sensible defaults when there are some.
The deployer, OTOH, has ready access to the app's environment,
including its Context, but should not be assumed to have such access to
the interior of the app.
So this division of labor depends on the developer's discipline in
distinguishing internal vs. external configuration and coding the app.
to look in the proper place for each. I don't see a good way for the
container to make up for incorrect design in this area.
That's perpetual dilemma for those of us who develop our apps for commercial
distribution.
We usually don't have access to a lot of needed information about the
deployment environment, and really don't want to know that much.
We don't normally have things like machine names, database names, schema
names and passwords, etc., and our customers are usually reluctant to provide
that information to us, at least prior to on-site install (if there is one).
So that sort of stuff has to be in a location that it is relatively easy to
point the SysAdmin towards and tell him what should be modified (or done via
an install script, where possible).
And in any case, I don't want to have to modify several hundred context.xml
or properties files, etc. and then generate individual war files for each
customer. I already have my hands full just creating the half-dozen
variations of our product each release.
Exactly my point. You shouldn't have to concern yourself with
instance details; those are the customer's concern, and the most
contact you should have with them is in the case that you want to
provide a wizard to write the instance configuration for the customer.
The customer only needs to know what the variables mean, in terms of
his operation, and how they are named.
${CATALINA_BASE}/conf/[enginename]/[hostname]/[appname].xml is easy to
find and should contain almost entirely only stuff that the customer
might need to adjust. Things the customer isn't concerned with
shouldn't be in there, outside of a couple of necessary attributes of
the Context element itself. You can supply a wizard to write it, if
need be.
If you want to do it all for the customer, you can ship a standard,
uncustomized WAR and a small file (perhaps a Context descriptor file)
with all the custom settings in it. You could probably build a Web
page to write the customizations file from a form and download it, if
the customers would accept that.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
Re: Tomcat thread dump analysis
Chris, Top-posting is a post after another one I'm assuming? And sorry if it wasn't related to Tomcat, I was just excited to finally making a bit of headway on this issue. Here is a full thread dump, sorry in advance if this doesn't follow the etiquette on posting thread dumps: TP-Processor396 daemon prio=10 tid=0x2aff2ba9d000 nid=0x5a7b waiting on condition [0x2aff61e98000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x2afecfb91da0 (a java.util.concurrent.Semaphore$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281) at java.util.concurrent.Semaphore.acquire(Semaphore.java:286) at com.tc.object.locks.LockStateNode$PendingLockHold.park(LockStateNode.java:179) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:723) at com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:701) at com.tc.object.locks.ClientLockImpl.lock(ClientLockImpl.java:52) at com.tc.object.locks.ClientLockManagerImpl.lock(ClientLockManagerImpl.java:98) at com.tc.object.bytecode.ManagerImpl.lock(ManagerImpl.java:747) at com.tc.object.bytecode.ManagerUtilInternal.beginLock(ManagerUtilInternal.java:33) at org.terracotta.locking.strategy.LongLockStrategy.beginLock(LongLockStrategy.java:16) at org.terracotta.locking.strategy.LongLockStrategy.beginLock(LongLockStrategy.java:7) at com.terracotta.toolkit.collections.ConcurrentDistributedMapDso.beginLock(ConcurrentDistributedMapDso.java:828) at com.terracotta.toolkit.collections.ConcurrentDistributedMapDso.get(ConcurrentDistributedMapDso.java:195) at com.terracotta.toolkit.collections.ConcurrentDistributedMapDsoArray.get(ConcurrentDistributedMapDsoArray.java:175) at org.terracotta.collections.ConcurrentDistributedMap.get(ConcurrentDistributedMap.java:190) at org.terracotta.cache.TerracottaDistributedCache.getNonExpiredEntry(TerracottaDistributedCache.java:197) at org.terracotta.cache.TerracottaDistributedCache.getNonExpiredEntryCoherent(TerracottaDistributedCache.java:131) at org.terracotta.cache.TerracottaDistributedCache.containsKey(TerracottaDistributedCache.java:126) at org.terracotta.modules.ehcache.store.ClusteredStore.internalContainsKey(ClusteredStore.java:476) at org.terracotta.modules.ehcache.store.ClusteredStore.containsKey(ClusteredStore.java:456) at org.terracotta.modules.ehcache.store.ClusteredStore.containsKeyInMemory(ClusteredStore.java:463) at net.sf.ehcache.Cache.searchInStoreWithStats(Cache.java:1742) at net.sf.ehcache.Cache.get(Cache.java:1405) at net.sf.ehcache.hibernate.regions.EhcacheTransactionalDataRegion.get(EhcacheTransactionalDataRegion.java:91) at net.sf.ehcache.hibernate.strategy.AbstractReadWriteEhcacheAccessStrategy.get(AbstractReadWriteEhcacheAccessStrategy.java:65) at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:524) at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:397) at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:165) at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:223) at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:126) at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:906) at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:874) at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:590) at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:219) at org.hibernate.type.TypeFactory.assemble(TypeFactory.java:443) at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:119) at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:105) at org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(DefaultLoadEventListener.java:587) at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:542) at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:397) at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:165) at
RE: Tomcat thread dump analysis
From: Charles Richard [mailto:charle...@thelearningbar.com] Subject: Re: Tomcat thread dump analysis Top-posting is a post after another one I'm assuming? No, it's doing what you keep on doing - posting the response before the query it applies to (you could have looked it up). It's obnoxious and makes it harder for people to follow the conversation. Here is a full thread dump Which again shows no Tomcat involvement in the locking hang. It would appear that logic in your application threads has either created a deadlock, or failed to unlock something before returning, or something else entirely (e.g, broken network causing grief with Terracotta's distributed caching). If it's a deadlock, you need to examine the entire thread dump (all threads) and look for a call stack that isn't like the others but holds the lock everyone else is waiting for. If it's simply a failure to unlock somewhere, you will likely have to do a thorough code review to find it. You will most likely need Terracotta's help here, since it's their code waiting on the lock. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fix CVE tomcat 6.0.18 with out upgrade
We are using tomcat 6.0.18 and we found below number of Common Vulnerabilities and Exposures (CVE). High Vulns: 98 Medium Vulns: 50 Low Vulns: 6 We cannot upgrade/patch any of those components due to supportability concerns from Autonomy. How can I apply a fix for all the CVE, I see the build instructions in below link but I was looking for applying the fixes without upgrade. Security - http://tomcat.apache.org/security-6.html#Apache_Tomcat_6.x_vulnerabilities Build Instructions - http://tomcat.apache.org/tomcat-6.0-doc/building.html Thanks
Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport
Am 2013-05-08 14:08, schrieb Nick Williams: On May 8, 2013, at 6:54 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 5/8/13 3:01 AM, Michael-O wrote: I recently have started using the SlowQueryReport to tackle performance issues. The log message, unfortunately, does not contain the parameters passed to the prepared statements. Though AbstractQueryReport receives this information in protected String report*Query(String query, Object[] args, final String name, long start, long delta) but ignores this information. The report would highly benefit from. E.g., Commons DBUtils prints out the query and the parameters in the case of an exception. The sole query isn't really helpful. Can we add this? Sure. Should I file a ticket? Yes. A BZ issue with a patch is likely to get done a whole lot faster than one without a patch (plus you get credit for your contribution). - -chris There needs to be an option to disable logging query parameters somehow. Query parameters are sometimes sensitive, and in some environments (medical, legal, etc.) logging them might even be in violation of the law. Agreed, but this won't work if someone failed to use prepared statements and uses StringBuilder to create the entire string. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport
Am 2013-05-08 14:38, schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/8/13 8:08 AM, Nick Williams wrote: On May 8, 2013, at 6:54 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 5/8/13 3:01 AM, Michael-O wrote: I recently have started using the SlowQueryReport to tackle performance issues. The log message, unfortunately, does not contain the parameters passed to the prepared statements. Though AbstractQueryReport receives this information in protected String report*Query(String query, Object[] args, final String name, long start, long delta) but ignores this information. The report would highly benefit from. E.g., Commons DBUtils prints out the query and the parameters in the case of an exception. The sole query isn't really helpful. Can we add this? Sure. Should I file a ticket? Yes. A BZ issue with a patch is likely to get done a whole lot faster than one without a patch (plus you get credit for your contribution). - -chris There needs to be an option to disable logging query parameters somehow. Query parameters are sometimes sensitive, and in some environments (medical, legal, etc.) logging them might even be in violation of the law. +1 If you really want to get cute, allow the user to specify named query parameters that should never be displayed e.g. 'password', though this is a) perhaps not possible and b) not reliable because you can bind parameters by position as well as by name. Java has no support for named parameters. How is that supposed to work? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fix CVE tomcat 6.0.18 with out upgrade
On May 8, 2013, at 12:11 PM, suresh babu yella wrote: We are using tomcat 6.0.18 and we found below number of Common Vulnerabilities and Exposures (CVE). Not surprising given the version that you are using. Latest version is 6.0.37. High Vulns: 98 Medium Vulns: 50 Low Vulns: 6 We cannot upgrade/patch any of those components due to supportability concerns from Autonomy. How can I apply a fix for all the CVE, I see the build instructions in below link but I was looking for applying the fixes without upgrade. You should really consider upgrading. Why are you so opposed to upgrading? Dan Security - http://tomcat.apache.org/security-6.html#Apache_Tomcat_6.x_vulnerabilities Build Instructions - http://tomcat.apache.org/tomcat-6.0-doc/building.html Thanks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport
Christopher, Am 2013-05-08 13:54, schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 5/8/13 3:01 AM, Michael-O wrote: I recently have started using the SlowQueryReport to tackle performance issues. The log message, unfortunately, does not contain the parameters passed to the prepared statements. Though AbstractQueryReport receives this information in protected String report*Query(String query, Object[] args, final String name, long start, long delta) but ignores this information. The report would highly benefit from. E.g., Commons DBUtils prints out the query and the parameters in the case of an exception. The sole query isn't really helpful. Can we add this? Sure. Should I file a ticket? Yes. A BZ issue with a patch is likely to get done a whole lot faster than one without a patch (plus you get credit for your contribution). What file should I patch, AbstractQueryReport or QueryReport? I'd exclude JMX for now. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fix CVE tomcat 6.0.18 with out upgrade
Hi Dan, We might consider for upgrading the tomcat later, due to to supportability concerns from Autonomy we cannot upgrade it to any of the higher version. but right now we are looking to apply the fix for all CVE's we identified, it will be great if you can let me know the procedure. Thanks Suresh On Wed, May 8, 2013 at 10:11 AM, Daniel Mikusa dmik...@gopivotal.comwrote: On May 8, 2013, at 12:11 PM, suresh babu yella wrote: We are using tomcat 6.0.18 and we found below number of Common Vulnerabilities and Exposures (CVE). Not surprising given the version that you are using. Latest version is 6.0.37. High Vulns: 98 Medium Vulns: 50 Low Vulns: 6 We cannot upgrade/patch any of those components due to supportability concerns from Autonomy. How can I apply a fix for all the CVE, I see the build instructions in below link but I was looking for applying the fixes without upgrade. You should really consider upgrading. Why are you so opposed to upgrading? Dan Security - http://tomcat.apache.org/security-6.html#Apache_Tomcat_6.x_vulnerabilities Build Instructions - http://tomcat.apache.org/tomcat-6.0-doc/building.html Thanks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fix CVE tomcat 6.0.18 with out upgrade
suresh babu yella suresh.b.ye...@gmail.com wrote: Hi Dan, We might consider for upgrading the tomcat later, due to to supportability concerns from Autonomy we cannot upgrade it to any of the higher version. but right now we are looking to apply the fix for all CVE's we identified, it will be great if you can let me know the procedure. The only available procedure is to upgrade. We do not provide patches for old releases. Mark Thanks Suresh On Wed, May 8, 2013 at 10:11 AM, Daniel Mikusa dmik...@gopivotal.comwrote: On May 8, 2013, at 12:11 PM, suresh babu yella wrote: We are using tomcat 6.0.18 and we found below number of Common Vulnerabilities and Exposures (CVE). Not surprising given the version that you are using. Latest version is 6.0.37. High Vulns: 98 Medium Vulns: 50 Low Vulns: 6 We cannot upgrade/patch any of those components due to supportability concerns from Autonomy. How can I apply a fix for all the CVE, I see the build instructions in below link but I was looking for applying the fixes without upgrade. You should really consider upgrading. Why are you so opposed to upgrading? Dan Security - http://tomcat.apache.org/security-6.html#Apache_Tomcat_6.x_vulnerabilities Build Instructions - http://tomcat.apache.org/tomcat-6.0-doc/building.html Thanks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fix CVE tomcat 6.0.18 with out upgrade
On May 8, 2013, at 1:17 PM, suresh babu yella wrote: Hi Dan, We might consider for upgrading the tomcat later, due to to supportability concerns from Autonomy we cannot upgrade it to any of the higher version. I don't know that vendor, but it sounds like you might need to have a conversation with them and see what is taking them so incredibly long (6.0.18 was released in Jul 2008) to upgrade. but right now we are looking to apply the fix for all CVE's we identified, it will be great if you can let me know the procedure. Each of the security issues that have been fixed are documented at the link you included. http://tomcat.apache.org/security-6.html#Apache_Tomcat_6.x_vulnerabilities You might be able to go through and apply mitigations for each of them, but that's going to be a long and tedious process. This is why you should really consider upgrading. That will bring everything up-to-date in one step. Dan Thanks Suresh On Wed, May 8, 2013 at 10:11 AM, Daniel Mikusa dmik...@gopivotal.comwrote: On May 8, 2013, at 12:11 PM, suresh babu yella wrote: We are using tomcat 6.0.18 and we found below number of Common Vulnerabilities and Exposures (CVE). Not surprising given the version that you are using. Latest version is 6.0.37. High Vulns: 98 Medium Vulns: 50 Low Vulns: 6 We cannot upgrade/patch any of those components due to supportability concerns from Autonomy. How can I apply a fix for all the CVE, I see the build instructions in below link but I was looking for applying the fixes without upgrade. You should really consider upgrading. Why are you so opposed to upgrading? Dan Security - http://tomcat.apache.org/security-6.html#Apache_Tomcat_6.x_vulnerabilities Build Instructions - http://tomcat.apache.org/tomcat-6.0-doc/building.html Thanks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat thread dump analysis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, On 5/8/13 11:25 AM, Caldarale, Charles R wrote: From: Charles Richard [mailto:charle...@thelearningbar.com] Subject: Re: Tomcat thread dump analysis Here is a full thread dump Which again shows no Tomcat involvement in the locking hang. +1 At least it confirms OP is actually running Tomcat, which wasn't evident from the first stack trace. Charles, please understand that what you have presented is a stack trace, not a thread dump: the difference is that a thread dump is a stack trace for every live thread in the JVM (which can show deadlocks) and you have provided only a single stack trace which cannot show a deadlock (it can only show that the thread is waiting on some condition). To demonstrate deadlock, you need to be able to see the condition being awaited in one thread, a lock held in another thread, and then the opposite scenario in another thread (or a single thread running into its own locks). Your stack trace does not show that the thread already holds the lock being awaited at the top of the stack trace. It is entirely possible that both Spring and Terrecotta attempt to synchronize on the same object (HttpSession) and that the thread is deadlocking on itself. If this is trivially-repeatable every time Terrecotta attempts to do whatever it is doing (hard to tell... Hibernate is executing a SQL query which ... uses the session?!?), then perhaps you have identified the problem and the Spring configuration to synchronize on a session attribute rather than the session itself will fix the problem. On the other hand, if the problem is different and yet you have arrived at your Spring + Terrecotta = deadlock conclusion due to treating Google as a consultant, then you may be barking up the wrong tree. Sorry: we like to get enough facts before we tell you a) what the problem is and b) how to fix it rather than just saying I Googled for 'terra cotta deadlock' and someone said that if you use Spring, you get deadlocks and telling you to go away. Instead, we'd rather help you fix your actual problem and educate you at the same time. It would appear that logic in your application threads has either created a deadlock, or failed to unlock something before returning, That's a tall order unless native code is involved, I believe. Though I don't have much experience with the java.lang.concurrent package... or something else entirely (e.g, broken network causing grief with Terracotta's distributed caching). If it's a deadlock, you need to examine the entire thread dump (all threads) and look for a call stack that isn't like the others but holds the lock everyone else is waiting for. If it's simply a failure to unlock somewhere, you will likely have to do a thorough code review to find it. You will most likely need Terracotta's help here, since it's their code waiting on the lock. +1 Start with finding out what Terrecotta is trying to lock on: if it's not the session, then you know you're entirely wrong about the cause. Also, knowing whether the thread is deadlocking itself versus another thread deadlocking with it is a very important piece of information to have. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRioxWAAoJEBzwKT+lPKRYz2AQAKbMT6qRh1oKvKdgBEUe1fJl yqgyB0JOkb9pZ42P2bVovJJtO5A15tWw8NigEbKc+CwJMv9rgOzqRY7y30oih9mK yhu5C/sEFDPlPPzt0H5CT3YFqVOoJMpstmgFBA0FBLKEaqmzdc61WIohQqJmv2J6 2z3vNvmH1xBucEqgOrOEn8mp9rbaOHVmQtf6Zh1QaxhBzA0CREnnwz0FvFEhklGx rlpwkQafjcKjCCP6eaiurtZJtv4S0hJQJSOmLQKBdm3DY/dRokeN/ROnxn3DpqfX e2JP4eAC2NYmKHwhXY3SOviK5Ha9NSB1fbBGSPSPQrjQ2In3UccYs6CENKOKUa68 0WwONHAw/OY0MzCJ6M9cZicX9XhNDNeRUzYlkORQpeAloM5w7Tp9q5fKo3iabFcC NwuWN5O5H5TZ2MSH7UHV9Kf0EA1Zk7Howi2Ea2zV4EnzutdgM5yxq//ow8LTcOdi ED376ckgSMgfV/b8u2tfJ1M9bD5WjD8v+kVbu+ErYzuM6i28iAGN7wrfgO+/Zn2S BuQgcEq/3usUXwnQ5IBAYpVF5DAKv/GeAaV+C8Ft+mb+jgo00Hb7Eqn5eY/w6CL/ 1DM0mgmfcHTlSP4JK5noV73Eip2LmxdPwDFvNBkIiRPq5Av+FSIfIKclJu/piMQ/ d0SCj26GbqSEIOYVUYX7 =3SsJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport
On May 8, 2013, at 12:08 PM, Michael-O wrote: Am 2013-05-08 14:38, schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/8/13 8:08 AM, Nick Williams wrote: On May 8, 2013, at 6:54 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 5/8/13 3:01 AM, Michael-O wrote: I recently have started using the SlowQueryReport to tackle performance issues. The log message, unfortunately, does not contain the parameters passed to the prepared statements. Though AbstractQueryReport receives this information in protected String report*Query(String query, Object[] args, final String name, long start, long delta) but ignores this information. The report would highly benefit from. E.g., Commons DBUtils prints out the query and the parameters in the case of an exception. The sole query isn't really helpful. Can we add this? Sure. Should I file a ticket? Yes. A BZ issue with a patch is likely to get done a whole lot faster than one without a patch (plus you get credit for your contribution). - -chris There needs to be an option to disable logging query parameters somehow. Query parameters are sometimes sensitive, and in some environments (medical, legal, etc.) logging them might even be in violation of the law. +1 If you really want to get cute, allow the user to specify named query parameters that should never be displayed e.g. 'password', though this is a) perhaps not possible and b) not reliable because you can bind parameters by position as well as by name. Java has no support for named parameters. How is that supposed to work? Agreed that it the setting won't be effective if they don't use prepared statements. Therefore, the setting name should reflect this restriction. I'm not sure what Chris is referring to. You are right, Java has no support for named parameters, even in Java 8. Chris might be thinking of Hibernate or Spring's JdbcTemplate, which permit using named parameters. Ultimately, these get converted to indexed parameters before the query is actually executed. Nick smime.p7s Description: S/MIME cryptographic signature
Re: Fix CVE tomcat 6.0.18 with out upgrade
On 5/8/13 1:17 PM, suresh babu yella wrote: Hi Dan, We might consider for upgrading the tomcat later, due to to supportability concerns from Autonomy we cannot upgrade it to any of the higher version. but right now we are looking to apply the fix for all CVE's we identified, it will be great if you can let me know the procedure. Then upgrade, but keep it within the Tomcat 6.0.x versions. Going up to 6.0.37 should be perfectly safe. Put up a test env and try it. --David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fix CVE tomcat 6.0.18 with out upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Suresh, On 5/8/13 12:11 PM, suresh babu yella wrote: We are using tomcat 6.0.18 and we found below number of Common Vulnerabilities and Exposures (CVE). High Vulns: 98 Medium Vulns: 50 Low Vulns: 6 We cannot upgrade/patch any of those components due to supportability concerns from Autonomy. How can I apply a fix for all the CVE Easy: C:\Program Files\Apache Software Foundation\Tomcat 6.0.18 bin\shutdown.sh Fixed. I see the build instructions in below link but I was looking for applying the fixes without upgrade. You would have to read the entire Subversion repository history involving Tomcat, evaluate each commit to determine its applicability to each CVE, apply them in order, fix any conflicts, then build the resulting source tree. Oh, and you'd then once again have an unsupported version of Tomcat (unsupported by both the ASF and Autonomy). Tomcat does not provide patches for CVEs: instead, the Tomcat team provides whole new versions that include (alleged) fixes for those CVEs. It's time to upgrade: you are hideously out of date. If Autonomy won't support running on a properly-patched version of Tomcat, then you shouldn't be running their software. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRio2AAAoJEBzwKT+lPKRY7bsP/24Zj3JyUI2IAkvpJHIOLom3 rJkIwsgj2fqugxY4pjFGjQKH/6hYTAlXJl+4SvWaI3JsQYpKpg0jTEXiVJNH5aNt hvGYEb0SLXQ4kjIY0LM/MtdFMms7lAABH2/ulIj3eQyTY/1xbJY9sUpZQvqX2TAB O4WwoM+mhtP+J1fUSiIT1SkeAjGvUkndsrO+Rmb4craR18yq5e49fsrL8UbsjNSF +579TywwiNW0JqefFn88AAXvtRUXQdnSNaeCTTIZOgbQqcDp+UoByWokOFc4jjon xpe5W2rQZCnwz5TDO7yNSUcJrtQA0YFEOUURgn5/Rxi6wSzRobSTuiKbXYq1+fuv Ju4RwzRc7+Zu/q5YtiWQd0/HUOmsxtO+9MuF/GmXGm8+FHEnP9YZZ46waRhfCd9Y iR1wbwW39ODWYIUUbL8TGqGvJpb/bvEj4oBidYFSe5BRMRKFEFZ69QY2UCJE8d70 +WWCXkTVv2sqKxkuJCqCheWlrhLRTWWJUeRIBKay4CJQvTPYx0itTX6CVH3Louve q7uXAagFh5Dftcq5pKQGM94Ot+ph2pGaipXzYzJE6UnAdoY4uuyZVLCPA0jUICx+ ld4yFFyXosXbG2ARFMphIbZmzEjnURbDKU+40IhHvBgTmZS0UA7bFjfdDDhdS2Gq ZP2D2XBEowuUulNkkqjl =w2M5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/8/13 1:34 PM, Nick Williams wrote: On May 8, 2013, at 12:08 PM, Michael-O wrote: Am 2013-05-08 14:38, schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/8/13 8:08 AM, Nick Williams wrote: On May 8, 2013, at 6:54 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 5/8/13 3:01 AM, Michael-O wrote: I recently have started using the SlowQueryReport to tackle performance issues. The log message, unfortunately, does not contain the parameters passed to the prepared statements. Though AbstractQueryReport receives this information in protected String report*Query(String query, Object[] args, final String name, long start, long delta) but ignores this information. The report would highly benefit from. E.g., Commons DBUtils prints out the query and the parameters in the case of an exception. The sole query isn't really helpful. Can we add this? Sure. Should I file a ticket? Yes. A BZ issue with a patch is likely to get done a whole lot faster than one without a patch (plus you get credit for your contribution). - -chris There needs to be an option to disable logging query parameters somehow. Query parameters are sometimes sensitive, and in some environments (medical, legal, etc.) logging them might even be in violation of the law. +1 If you really want to get cute, allow the user to specify named query parameters that should never be displayed e.g. 'password', though this is a) perhaps not possible and b) not reliable because you can bind parameters by position as well as by name. Java has no support for named parameters. How is that supposed to work? Agreed that it the setting won't be effective if they don't use prepared statements. Therefore, the setting name should reflect this restriction. I'm not sure what Chris is referring to. You are right, Java has no support for named parameters, even in Java 8. Chris might be thinking of Hibernate or Spring's JdbcTemplate, which permit using named parameters. Ultimately, these get converted to indexed parameters before the query is actually executed. I'm talking about java.sql.ResultSet.updateFoo(String columnName, Foo fooData) Or are all your queries SELECTs? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRio4WAAoJEBzwKT+lPKRY3MsP/3CaNjAgFlEU0kOQX0cpGBQC LF4+Mq4oGwtB8YOOzr/P6mCSaQC/x2SNoOZiBWv4ZNEw8F82UuEKEW+/UetR9rPL eumv7g8W6kWxM9v4/GQlF93Onw7qNtGw/eA9j/MyTebCUxQR9Uil+qY1UGZSJGPq LD1BaGN8Fc12bsYB/WYqCHIThC3zoI+ixley+fTVF0Dc3vc4atgkjmBZmMxE+Rqi WD66fQuIPOXoM2lBN5Z4motg/vBwcl/0CZs5bAiNSDfXbhMjgN5TRdYESI4eKjCw bR1/rTRV2uix0UXOJWYW5H9mbccqkdcUs3GHGb9picTUehsmvPP5XCXbdBekiRZE pbsKeUB/Fx0CDM8yID0jqZdSRe+EHq3PlvbJvvzDWuvGH3ND7ZfwwAkz4kNy4xIK xwvXDGbjgtThHIfszmaP3K+vdbaTHpX72ejIRspiY4R8zlB4hpl/vNq+lJEZGApH 1PCFyB6SNlKxnl3ssMqSDXEbBcTGF1KFQAiFLzjXzL5KZDwCzmoWloyJp0ZCTL8t nNhCgicZsGb4NV/0CIDgj2GhHegfwykFkKyawSKZ8jJtvi07FnCHvRwyTjqYJRfR fORpk45iVmEXnB9W1YWxb8xRlkpzwIo6aVUpNTPazrNawz00yUhbmsUQ54v5tson utTyDNO+0DXQ6zsWFFu4 =wBws -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 5/8/13 1:14 PM, Michael-O wrote: Christopher, Am 2013-05-08 13:54, schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 5/8/13 3:01 AM, Michael-O wrote: I recently have started using the SlowQueryReport to tackle performance issues. The log message, unfortunately, does not contain the parameters passed to the prepared statements. Though AbstractQueryReport receives this information in protected String report*Query(String query, Object[] args, final String name, long start, long delta) but ignores this information. The report would highly benefit from. E.g., Commons DBUtils prints out the query and the parameters in the case of an exception. The sole query isn't really helpful. Can we add this? Sure. Should I file a ticket? Yes. A BZ issue with a patch is likely to get done a whole lot faster than one without a patch (plus you get credit for your contribution). What file should I patch, AbstractQueryReport or QueryReport? I'd exclude JMX for now. Your choice: whatever seems to make more sense. If a committer reads and patch and thinks it goes somewhere else, you can re-write it. Or, you can open the BZ issue, then post to the dev list asking for suggestions for where to start. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRio5uAAoJEBzwKT+lPKRYLuwP+wXOVVxKGvPO7GCXZyd/p8bz g7KZ+wt6cxUpLL/cD2tfBhpFn5rMRHm/40E3P2O62moZOl0cB9ObjL0JaPCGD+Fu eTf7hqW/ldVsRIOcYaeQZ0hZ0nQXWrQetobcOU1aAZ6tA/OTgzaR1qVZvygzU86H wEjW9gWQhpnVpjd1M+YrOo4XH48mj1/c2OjHDSMhJhEVgg5qPEmXv5u7hHbdEOyF ctMx94shFhAhP0PzcJ9Ea71F8zL61cjhbbPr7mVR9SWHCbAol223he6T9nIiuUtO ABisryyQ8PpN54TCVNHcRhAFXkrkIR6dylhV50FbWJqfjOAhn46L/Q2eHsbeUv4c hw7RgmE26W4fi86zLPxuvcwLJYDkSe/4dTmBjV7RP6y9UreDcj+5MjuSqcSkQEpl +B4+R1VnQVv6f3tZ1w9QAB9KbdroHKjDCyb0bnhCSUT6OpKLffU6iz+6N982OVmR ruOf8+xEIGwbQmj+siFRh6Hb06o6puZOo2O/4ZC3YhEiSoKOkhO48mRzZtAh1mVg w/X2VQtKZpOGhql3wKU0N+nV3XtO0KB+JGI4V98MTbL9IL4TVtUsd1xgKKoQOc2F +quRNg1+jRrV718YYjxdATlZLGSsq++GjfLzqZRhoeSlTV4ITwF9NZSKWjFxv0/W 2Zfw/8U+K0B1wBNvvZ+A =wWhP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport
On May 8, 2013, at 12:40 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/8/13 1:34 PM, Nick Williams wrote: On May 8, 2013, at 12:08 PM, Michael-O wrote: Am 2013-05-08 14:38, schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/8/13 8:08 AM, Nick Williams wrote: On May 8, 2013, at 6:54 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 5/8/13 3:01 AM, Michael-O wrote: I recently have started using the SlowQueryReport to tackle performance issues. The log message, unfortunately, does not contain the parameters passed to the prepared statements. Though AbstractQueryReport receives this information in protected String report*Query(String query, Object[] args, final String name, long start, long delta) but ignores this information. The report would highly benefit from. E.g., Commons DBUtils prints out the query and the parameters in the case of an exception. The sole query isn't really helpful. Can we add this? Sure. Should I file a ticket? Yes. A BZ issue with a patch is likely to get done a whole lot faster than one without a patch (plus you get credit for your contribution). - -chris There needs to be an option to disable logging query parameters somehow. Query parameters are sometimes sensitive, and in some environments (medical, legal, etc.) logging them might even be in violation of the law. +1 If you really want to get cute, allow the user to specify named query parameters that should never be displayed e.g. 'password', though this is a) perhaps not possible and b) not reliable because you can bind parameters by position as well as by name. Java has no support for named parameters. How is that supposed to work? Agreed that it the setting won't be effective if they don't use prepared statements. Therefore, the setting name should reflect this restriction. I'm not sure what Chris is referring to. You are right, Java has no support for named parameters, even in Java 8. Chris might be thinking of Hibernate or Spring's JdbcTemplate, which permit using named parameters. Ultimately, these get converted to indexed parameters before the query is actually executed. I'm talking about java.sql.ResultSet.updateFoo(String columnName, Foo fooData) Or are all your queries SELECTs? Interesting. My (possible incorrect) understanding of ResultSet.updateFoo is that it does not execute a SQL statement. The database server has the cursored log held in memory and a direct binary message is sent back to update that column on that record. Therefore, there is no SQL statement to be logged by the SlowQueryReport. My (again, possibly incorrect) understanding of the SlowQueryReport is that it only applies to Statements, PreparedStatements, and CallableStatements. These only have indexed parameters. smime.p7s Description: S/MIME cryptographic signature
Re: Tomcat thread dump analysis
On Wed, May 8, 2013 at 2:33 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, On 5/8/13 11:25 AM, Caldarale, Charles R wrote: From: Charles Richard [mailto:charle...@thelearningbar.com] Subject: Re: Tomcat thread dump analysis Here is a full thread dump Which again shows no Tomcat involvement in the locking hang. +1 At least it confirms OP is actually running Tomcat, which wasn't evident from the first stack trace. Charles, please understand that what you have presented is a stack trace, not a thread dump: the difference is that a thread dump is a stack trace for every live thread in the JVM (which can show deadlocks) and you have provided only a single stack trace which cannot show a deadlock (it can only show that the thread is waiting on some condition). To demonstrate deadlock, you need to be able to see the condition being awaited in one thread, a lock held in another thread, and then the opposite scenario in another thread (or a single thread running into its own locks). Your stack trace does not show that the thread already holds the lock being awaited at the top of the stack trace. I appreciate the friendly feedback! How do I show a lock? I don't see any threads that have a BLOCKED status. I do get this when I do a grep: [root@web01 stacks]# grep locked tomcat1_20130507_14\:38.stack | wc -l 154 My connection pool is 150 and I do see 150 locks in the following type scenario which has a locked: TP-Processor416 daemon prio=10 tid=0x2aff2939a800 nid=0x5ae7 in Object.wait() [0x2aff632ae000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x2afe240fbc58 (a com.mchange.v2.resourcepool.BasicResourcePool) at com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1315) at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:557) - locked 0x2afe240fbc58 (a com.mchange.v2.resourcepool.BasicResourcePool) It is entirely possible that both Spring and Terrecotta attempt to synchronize on the same object (HttpSession) and that the thread is deadlocking on itself. If this is trivially-repeatable every time Terrecotta attempts to do whatever it is doing (hard to tell... Hibernate is executing a SQL query which ... uses the session?!?), then perhaps you have identified the problem and the Spring configuration to synchronize on a session attribute rather than the session itself will fix the problem. On the other hand, if the problem is different and yet you have arrived at your Spring + Terrecotta = deadlock conclusion due to treating Google as a consultant, then you may be barking up the wrong tree. Sorry: we like to get enough facts before we tell you a) what the problem is and b) how to fix it rather than just saying I Googled for 'terra cotta deadlock' and someone said that if you use Spring, you get deadlocks and telling you to go away. Instead, we'd rather help you fix your actual problem and educate you at the same time. I agree. At times desperate times call for desperate actions when I've used all existing knowledge, Google can give me ideas of where I could possibly look next. Given the choice, I would rather be educated on how to diagnose this issue properly. It would appear that logic in your application threads has either created a deadlock, or failed to unlock something before returning, That's a tall order unless native code is involved, I believe. Though I don't have much experience with the java.lang.concurrent package... or something else entirely (e.g, broken network causing grief with Terracotta's distributed caching). If it's a deadlock, you need to examine the entire thread dump (all threads) and look for a call stack that isn't like the others but holds the lock everyone else is waiting for. If it's simply a failure to unlock somewhere, you will likely have to do a thorough code review to find it. You will most likely need Terracotta's help here, since it's their code waiting on the lock. +1 Start with finding out what Terrecotta is trying to lock on: if it's not the session, then you know you're entirely wrong about the cause. Also, knowing whether the thread is deadlocking itself versus another thread deadlocking with it is a very important piece of information to have. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRioxWAAoJEBzwKT+lPKRYz2AQAKbMT6qRh1oKvKdgBEUe1fJl yqgyB0JOkb9pZ42P2bVovJJtO5A15tWw8NigEbKc+CwJMv9rgOzqRY7y30oih9mK yhu5C/sEFDPlPPzt0H5CT3YFqVOoJMpstmgFBA0FBLKEaqmzdc61WIohQqJmv2J6 2z3vNvmH1xBucEqgOrOEn8mp9rbaOHVmQtf6Zh1QaxhBzA0CREnnwz0FvFEhklGx
Re: Tomcat thread dump analysis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles, On 5/8/13 1:57 PM, Charles Richard wrote: I appreciate the friendly feedback! How do I show a lock? I don't see any threads that have a BLOCKED status. I do get this when I do a grep: [root@web01 stacks]# grep locked tomcat1_20130507_14\:38.stack | wc -l 154 My connection pool is 150 and I do see 150 locks in the following type scenario which has a locked: TP-Processor416 daemon prio=10 tid=0x2aff2939a800 nid=0x5ae7 in Object.wait() [0x2aff632ae000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x2afe240fbc58 (a com.mchange.v2.resourcepool.BasicResourcePool) This only tells you the identity of the object monitor (the lock). What you are missing is the identities of the object monitors already held by this and other threads. I believe your thread dump does not include any of these. IIRC, the Oracle JVM can (when prodded) produce a thread dump which includes deadlock detection and will show the suspected-deadlocked threads, the held lock ids and what threads are waiting on. Perhaps you can get a better thread dump via other means? How did you get the one you have now? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRisCwAAoJEBzwKT+lPKRYmlMP/35U86kwWXyYPVC3ejSTvF0O OHnn+RDbNLX2Qt1s4ALEUBl7rU4fu3hOEaG04DVzs17Ni/fongDzBhEdWyzcSGui JeJzAyoZBj2bc86mLf5NraAZRiZakdrqr6iWaQt1bhgKde5TsoP1qn4+5oPsYzEw HhOveggibKaLZkhheZZFAvFFrbpFM7IblrYyA7905b7Q2ZluvRdqEkcm5NR9LxOJ Zdrn3e3v0vV9rpTDtvi+nHlHHtj7VpJkaOCLQH8ra2az9Nq/ZXqhLROEdsA5hYJt PjUooQYYCq09J0yi3uujBzOyiC3hosSoo02dclknil4Ib6SlGfejsN0eUY3IAPoY By/AZ+ybz9oa8ts52NwARpaQvoINzNnFWE5Gq9jU0RqEUdLP0ociRrbWsCb8UjFk jmLRU5lYG287MwviKtYHPilR/Dt4fD9YAab5tuP+v5XULFEbN5INtFcnYiWpNLxm MCAvORVyYrWAgrRXR9JNtN8ZouX/CygHiV/312JKJwCnj34TqrYYXjhDaGqUq368 4QH5ZkJYAsEUa53W6zsxp0PS1EkKjgQ4LFqgFqmZdA/c874tF9WjtO2obWyIqHan WQkNDUTW1pahp+4v+Fyh7QfwqbO8PVtg2lqWNfkHK1gEkIAF30/Wo3IrbTtfUYJu 7yoQIzW3qJRRdVJ8Id3S =Xkzn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Remove default files, example JSPs and Servlets from the Tomcat Servlet/JSP container.
Hi, We are using tomcat 6.0.18 and we got common vulnerability reported for having default files, example JSPs and Servlets from the Tomcat Servlet/JSP container. I need a steps to Remove default files, example JSPs and Servlets from the Tomcat Servlet/JSP container. Thanks Sures
RE: Remove default files, example JSPs and Servlets from the Tomcat Servlet/JSP container.
From: suresh babu yella [mailto:suresh.b.ye...@gmail.com] Subject: Remove default files, example JSPs and Servlets from the Tomcat Servlet/JSP container. We are using tomcat 6.0.18 If you actually had any concern for security, you would not be using a version that's nearly five years old. we got common vulnerability reported for having default files, example JSPs and Servlets from the Tomcat Servlet/JSP container. That's the least of your worries. I need a steps to Remove default files, example JSPs and Servlets from the Tomcat Servlet/JSP container. The rm commands works for me, but you might want to undeploy the undesirable webapps first. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat thread dump analysis
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Tomcat thread dump analysis It would appear that logic in your application threads has either created a deadlock, or failed to unlock something before returning, That's a tall order unless native code is involved, I believe. Nope, it's terribly easy with java.util.concurrent. For example, you can create Semaphore objects, and then forget to call release() after calling acquire(). It's not block-structured like synchronization constructs built into the Java language. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Catalina.policy java.security.AllPermission
Hi, I have a problem with the Catalina’s security manager. We are using Tomcat 6, with JDK 6 and JSF 2.1 with Spring, JPA and ICEFaces. My app works very well when I run my app with the security manager disable. The problem presents when I enable the security manager of Tomcat. My app fails when Tomcat start giving me the next log: INFO: Checking whether login URL '/security/login.jsf' is accessible with your configuration 8/05/2013 12:29:11 PM org.springframework.web.context.ContextLoader initWebApplicationContext INFO: Root WebApplicationContext: initialization completed in 1969 ms 8/05/2013 12:29:11 PM org.apache.catalina.core.StandardContext start SEVERE: Error listenerStart 8/05/2013 12:29:11 PM org.apache.catalina.core.StandardContext start SEVERE: Falló en arranque del Contexto [/WebRed] debido a errores previos 8/05/2013 12:29:11 PM com.sun.faces.config.ConfigureListener contextDestroyed SEVERE: Unexpected exception when attempting to tear down the Mojarra runtime java.lang.NullPointerException at com.sun.faces.config.ConfigureListener.getInitFacesContext(ConfigureListener.java:740) at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:300) at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4245) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4886) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4750) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799) at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:124) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:146) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:777) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:943) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:563) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1399) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:762) at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1500) at org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.java:252) at javax.servlet.http.HttpServlet.service(HttpServlet.java:643) at javax.servlet.http.HttpServlet.service(HttpServlet.java:723) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:276) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:170) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:283) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) at org.apache.catalina.filters.CsrfPreventionFilter.doFilter(CsrfPreventionFilter.java:194) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:276) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:250) at
