Re: svn commit: r887992 - in /tomcat/trunk/java/org/apache/catalina: core/ApplicationDispatcher.java core/ApplicationFilterChain.java core/StandardWrapperValve.java deploy/FilterDef.java startup/Con
sebb wrote: > On 07/12/2009, ma...@apache.org wrote: >> -// FIXME: Exception handling needs to be simpiler to what is >> in the StandardWrapperValue >> +// FIXME: Exception handling needs to be simpler to what is in >> the StandardWrapperValue > > Should that be "similar to" ? > > If it really is "simpler", then it would be "simpler than". Probably. I'll go look at the code and figure out which. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DBCP 1.3/1.4
Commons is close to the next DBCP release. I have been looking at this and there will, unfortunately, still be some Java 5 with JDBC 3 / Java 6 with JDBC 4 issues. It isn't possible to work around them without a complete refactoring and/or multiple JARs and/or use of something like BCEL. Rather than introduce any of this complexity, I recommend the following approach. Continue to ship Tomcat 6 with Java 5 built JDBC 3 support Ship Tomcat 7 with Java 6 built JDBC 4 support For the rare occasions where folks using Tomcat 6 want JDBC 4 support (from the lack of posts on this topic on the users list I don't think there are that many of them) they can grab the dbcp jar from Tomcat 7 and use that instead. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DBCP 1.3/1.4
[I know I'm missing something .. but] Would it be worth dropping dbcp from 7 and just use jdbc-pool? -Tim Mark Thomas wrote: Commons is close to the next DBCP release. I have been looking at this and there will, unfortunately, still be some Java 5 with JDBC 3 / Java 6 with JDBC 4 issues. It isn't possible to work around them without a complete refactoring and/or multiple JARs and/or use of something like BCEL. Rather than introduce any of this complexity, I recommend the following approach. Continue to ship Tomcat 6 with Java 5 built JDBC 3 support Ship Tomcat 7 with Java 6 built JDBC 4 support For the rare occasions where folks using Tomcat 6 want JDBC 4 support (from the lack of posts on this topic on the users list I don't think there are that many of them) they can grab the dbcp jar from Tomcat 7 and use that instead. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r888499 - /tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
Author: markt
Date: Tue Dec 8 17:59:57 2009
New Revision: 888499
URL: http://svn.apache.org/viewvc?rev=888499&view=rev
Log:
Correct TODO - thanks sebb
Modified:
tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
Modified: tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java?rev=888499&r1=888498&r2=888499&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java Tue
Dec 8 17:59:57 2009
@@ -704,7 +704,7 @@
} catch (Throwable e) {
wrapper.getLogger().error(sm.getString("standardWrapper.releaseFilters",
wrapper.getName()), e);
-// FIXME: Exception handling needs to be simpler to what is in the
StandardWrapperValue
+// FIXME: Exception handling needs to be similar to what is in the
StandardWrapperValue
}
// Deallocate the allocated servlet instance
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DBCP 1.3/1.4
Tim Funk wrote: > [I know I'm missing something .. but] Would it be worth dropping dbcp > from 7 and just use jdbc-pool? I think dropping dbcp would be bad - it is something that is familiar to lots of users. +1 to including jdbc-pool Which one to make the default? My very rough (not really thought out and I haven't looked at the code) post commons-dbcp 1.4 and commons-pool 1.5.4 ideas are, since both need a major refactoring, lets use jdbc-pool as the basis for some of that refactoring and essentially bring the two code bases together. How viable that is and how long it might take is very TBD. Mark > > -Tim > > > Mark Thomas wrote: >> Commons is close to the next DBCP release. >> >> I have been looking at this and there will, unfortunately, still be some >> Java 5 with JDBC 3 / Java 6 with JDBC 4 issues. It isn't possible to >> work around them without a complete refactoring and/or multiple JARs >> and/or use of something like BCEL. >> >> Rather than introduce any of this complexity, I recommend the following >> approach. >> >> Continue to ship Tomcat 6 with Java 5 built JDBC 3 support >> Ship Tomcat 7 with Java 6 built JDBC 4 support >> >> For the rare occasions where folks using Tomcat 6 want JDBC 4 support >> (from the lack of posts on this topic on the users list I don't think >> there are that many of them) they can grab the dbcp jar from Tomcat 7 >> and use that instead. > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "FAQ/Performance_and_Monitori ng" by BjornFreemanBenson
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "FAQ/Performance_and_Monitoring" page has been changed by BjornFreemanBenson. http://wiki.apache.org/tomcat/FAQ/Performance_and_Monitoring?action=diff&rev1=4&rev2=5 -- * Stress test your webapp. You can do this via [[http://jakarta.apache.org/jmeter/|JMeter]], [[http://www.joedog.org/siege/|siege]], [[http://httpd.apache.org/test/flood/|flood]], and other tools. Google is your friend. * Tweak your UNIX box! Look at ulimit and kernel parameters. * Bad design will hurt performance. - * Look at [[http://java.quest.com/jprobe/jprobe.shtml|JProbe]], or [[http://www.borland.com/optimizeit/|OptimizeIt]], or other profiling tools. Lots of people recommend these tools. This is not an endorsement for them, I just notice other people like them. + * Look at [[http://java.quest.com/jprobe/jprobe.shtml|JProbe]], or [[http://www.borland.com/optimizeit/|OptimizeIt]], or [[http://www.newrelic.com/RPMlite.html|New Relic]], or other profiling tools. Lots of people recommend these tools. This is not an endorsement for them, I just notice other people like them. == Questions == 1. [[#Q1|Is Tomcat faster than serving static HTML pages than Apache httpd?]] 1. [[#Q2|Is there an application-specific comparison between Tomcat and Resin or other containers?]] 1. [[#Q3|Is there a comprehensive, up-to-date, detailed benchmark comparing various servlet containers, including Tomcat?]] + == Answers == <>'''Is Tomcat faster than serving static HTML pages than Apache httpd?''' - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DBCP 1.3/1.4
On 12/08/2009 11:04 AM, Mark Thomas wrote: Tim Funk wrote: [I know I'm missing something .. but] Would it be worth dropping dbcp from 7 and just use jdbc-pool? I think dropping dbcp would be bad - it is something that is familiar to lots of users. familiar in what sense? how would jdbc-pool be unfamiliar in terms of config? I would say the opposite, most users wouldn't even know the difference, especially since we don't ship org.apache.commons.dbcp, but we refactor it to org.apache.tomcat.dbcp +1 to including jdbc-pool I'd be all for that :) Which one to make the default? given the interface issues with DBCP, sounds like jdbc-pool might be an easier way to go. jdbc-pool is a bit more flexible should the need to add features arise. My very rough (not really thought out and I haven't looked at the code) post commons-dbcp 1.4 and commons-pool 1.5.4 ideas are, since both need a major refactoring, lets use jdbc-pool as the basis for some of that refactoring and essentially bring the two code bases together. How viable that is and how long it might take is very TBD. the only downside to my suggestions above is that jdbc-pool doesn't have much developer community around it. the usage of it has grown, and the bug reports have been very few and no major issues are outstanding. unless we can build a community around it, we need to figure out what to do with it. Filip Mark -Tim Mark Thomas wrote: Commons is close to the next DBCP release. I have been looking at this and there will, unfortunately, still be some Java 5 with JDBC 3 / Java 6 with JDBC 4 issues. It isn't possible to work around them without a complete refactoring and/or multiple JARs and/or use of something like BCEL. Rather than introduce any of this complexity, I recommend the following approach. Continue to ship Tomcat 6 with Java 5 built JDBC 3 support Ship Tomcat 7 with Java 6 built JDBC 4 support For the rare occasions where folks using Tomcat 6 want JDBC 4 support (from the lack of posts on this topic on the users list I don't think there are that many of them) they can grab the dbcp jar from Tomcat 7 and use that instead. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat-jdbc pool interceptor
hi Kevin,
hi Kevin, what you seem to be missing in your config is
testOnBorrow="true"
Filip
On 12/02/2009 05:11 AM, Kevin Jackson wrote:
Hi,
We have a situation with a clustered SQL Server database and tomcat-jdbc.
When the cluster fails over and the active node switches to the
passive node, all the open connections in the tomcat-jdbc pool become
invalid, but SQL Server doesn't report this and the connection remains
'ESTABLISHED' [see http://support.microsoft.com/kb/273673/]
The stack trace we commonly see is:
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.apache.tomcat.jdbc.pool.ProxyConnection.invoke(ProxyConnection.java:78)
... 43 more
Caused by: java.sql.SQLException: Invalid state, the Connection object
is closed.
at
net.sourceforge.jtds.jdbc.ConnectionJDBC2.checkOpen(ConnectionJDBC2.java:1634)
at
net.sourceforge.jtds.jdbc.ConnectionJDBC2.prepareStatement(ConnectionJDBC2.java:2328)
... 47 more
Currently we have set the following params:
removeAbandoned="true"
logAbandoned="true"
maxActive="100"
maxIdle="30"
minIdle="20"
initialSize="20"
maxWait="1"
validationQuery="SELECT count(1) from xyz"
Although it's traditional to simply use 'select 1' as the
validationQuery for SQL Server, we want to ensure that the query isn't
actually optimized out at some point in the driver.
To avoid the problem with failovers, I think we have a couple of options:
#1 add the following config:
testWhileIdle="true"
timeBetweenEvictionRunsMillis="3"
This should evict any stale connections every 5 mins (if the idleness
test is valid and it appears to be so having read the src for
PooledConnection and ConnectionPool)
#2 write a very simple JdbcInterceptor which checks the connection on reset:
package org.apache.tomcat.jdbc.pool.interceptor;
import java.sql.Statement;
import org.apache.tomcat.jdbc.pool.ConnectionPool;
import org.apache.tomcat.jdbc.pool.JdbcInterceptor;
import org.apache.tomcat.jdbc.pool.PoolConfiguration;
import org.apache.tomcat.jdbc.pool.PooledConnection;
/**
* If the underlying database has failed over (in active-passive configuration)
* the connections need to be closed
* @author k...@apache.org
*/
public class FailoverHandler extends JdbcInterceptor {
@Override
public void reset(ConnectionPool parent, PooledConnection con) {
if(null == parent || null == con) return; //nothing to do
PoolConfiguration config = parent.getPoolProperties();
Statement stmt = null;
try {
stmt = con.getConnection().createStatement();
stmt.execute(config.getValidationQuery());
stmt.close();
} catch (Exception e) {
//on any exception, assume that the connection is stale
//and completely remove it from pool, also force a
check of all
idle connections
con.release();
parent.testAllIdle();
}
}
}
With this approach we are trading a significant amount of performance
for some reliability of the connection not being stale. I'm happy
with this trade-off if the interceptor is correct (I know it's not
bomb-proof as I really should have null guards around everything)
Would anyone who has knowledge of this particular code-base be able to
tell me if release() + testAllIdle() will give me the kind of
guarantee I'm after or if the configuration of testWhileIdle +
timeBetweenEvictionRunsMillis is just as valid?
Thanks,
Kev
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat 7 - META-INF/context.xml
I would like to suggest that context.xml files that are contained within directories or WAR files do not get copied to a sub directory under "conf" where it remains if the war file or directory is removed while the server is shutdown. Copying the file META-INF/context.xml has never made much sense to me on why that was necessary or logical, it seems as a WAR file is self contained, and should remain so. what ya say? Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DBCP 1.3/1.4
Hi, > familiar in what sense? how would jdbc-pool be unfamiliar in terms of > config? > I would say the opposite, most users wouldn't even know the difference, > especially since we don't ship org.apache.commons.dbcp, but we refactor it > to org.apache.tomcat.dbcp This refactor has caused queries in the past and I know I have tried to add commons-dbcp to a webapp myself... > >> +1 to including jdbc-pool >> for what it's worth +1 from me. > given the interface issues with DBCP, sounds like jdbc-pool might be an > easier way to go. > jdbc-pool is a bit more flexible should the need to add features arise. > the only downside to my suggestions above is that jdbc-pool doesn't have > much developer community around it. > the usage of it has grown, and the bug reports have been very few and no > major issues are outstanding. > unless we can build a community around it, we need to figure out what to do > with it. We currently use tomcat-jdbc-pool in production here and as an apache member I'm quite happy to help support it and help with bugfixes etc (indeed I'm sure my company would encourage that) as we regard it as a vital piece of our current architecture. Thanks, Kev - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
