http://pesticidesinfresnoca.blogspot.com/2008/03/dibromochloropropane-dbcp-in-fresno-ca.html

To save others the pain, I've documented all the problems I've found, and how I solved them, in this blog entry. I'll keep updating this as I find new ones.

Java Bean Introspection

The Java bean introspector keeps a cache that doesn't get flushed. It's hard to know if this is a problem for you without profiling - your application probably doesn't use the introspector, but some libraries that you use might.

To fix this problem you need to create a ServletContextListener in your app and add the following clean-up code to the "contextDestroyed" method.

[sourcecode language='java']
Introspector.flushCaches();
[/sourcecode]

If you're using Spring, you should add the IntrospectorCleanupListener to your web.xml instead (this calls Instrospector.flushCaches() for you, as well as doing some additional cleanup).

Commons Pool Eviction Timer

In old versions of commons pool, the eviction timer was not being cleaned up when the webapp shut down. This issue has been fixed in the version 1.4 of commons-pool, so if you use commons-pool, make sure you're using at least version 1.4.

As a side note, if you're using commons-dbcp (which uses commons-pool) you should also make sure you're using at least version 1.2.2, as it fixes a swag of issues some of which we've seen in our production systems.

MySQL Connector/J Statement Cancellation Timer

Version 5.1.6 (and earlier) of the MySQL JDBC driver (Connector/J) has a problem whereby the statement cancellation timer in the ConnectionImpl class is never cancelled, resulting in the timer thread hanging around even after you've unloaded your app. If you use the MySQL JDBC driver this will be a problem for you.

I've raised a bug report with the MySQL folks. In the meantime you can create a ServletContextListener in your app and add the following clean-up code to the "contextDestroyed" method.

[sourcecode language='java']
try {
if (ConnectionImpl.class.getClassLoader() == getClass().getClassLoader()) {
Field f = ConnectionImpl.class.getDeclaredField("cancelTimer");
f.setAccessible(true);
Timer timer = (Timer) f.get(null);
timer.cancel();
}
}
catch (Exception e) {
System.out.println("Exception cleaning up MySQL cancellation timer: " + e.getMessage());
}
[/sourcecode]

JDBC Driver Manager

The JDBC Driver Manager is notorious for causing PermGen memory leaks. When a JDBC driver starts up it gets registered with the global DriverManager, but never de-registered. If you are using any sort of JDBC driver, this will be a problem for you.

To fix this problem you need to create a ServletContextListener in your app and add the following clean-up code to the "contextDestroyed" method.

[sourcecode language='java']
try {
for (Enumeration e = DriverManager.getDrivers(); e.hasMoreElements(); ) {
Driver driver = (Driver) e.nextElement();
if (driver.getClass().getClassLoader() == getClass().getClassLoader()) {
DriverManager.deregisterDriver(driver);
}
}
}
catch (Throwable e) {
System.out.println("Unable to clean up JDBC driver: " + e.getMessage());
}
[/sourcecode]

DOM4J ThreadLocal leaks

Older versions of DOM4J store data in ThreadLocal variables that never get cleaned up. This problem has been fixed in recent versions of DOM4J. If you're using DOM4J make sure you use at least version 1.6.1.

Xerces XML Libraries

Tomcat uses the SAXParser to read in configuration files. If you include Xerces in your webapp's WEB-INF/lib directory Tomcat will use this rather than the one in the JDK. This is bad because Tomcat maintains a reference to this parser, which will prevent your webapp's ClassLoader from being collected.

The fix is to remove the xerces and XML parser API libs from your webapp. If you're running Java 5 or better these are included in the JRE so you don't need them. If you're using an older JRE, put the jars into the container's shared library folder ("common/lib" in Tomcat).

Quartz Scheduler ShutdownHook

The Quartz ShutdownHookPlugin registers a hook with the Java runtime that doesn't get cleaned up if you simply unload your webapp (it will only get cleaned up when you shut down the JVM).

The solution is to not use the ShutdownHookPlugin at all. If you're using the Spring Quartz wrappers, you simply configure the Spring bean factory to clean up Quartz when the bean factory is destroyed. Otherwise it's a simple job to add a ServletContextListener to clean up Quartz when your application shuts down.

Tomcat and Commons Logging

Earlier versions of Tomcat had a problem with leaking PermGen memory when a webapp included commons-logging in its WEB-INF/lib. Later versions fixed this problem, so make sure you're running at least version 5.5.16.

Other Resources

Here are some other resources that you might find useful in finding/fixing your PermGen leaks:

• Spring Wiki

Good luck!

Fresno, CA       Water tampering / apparent diversion of water. Beneath the surface i.e., under the streets, homes (old and NEW construction), lawns, sidewalks is evidence of a 45+/- yr operation that is now being tied into the "infrastructure upgrade." Ringleader is Swieso, a former employee of the City of Fresno. This is behind the decades of sewage back spills, forged/fraudulent paperwork, and talk of re-routing water for development at Friant. He personally gave me a tour of the vacant lots he owned in the area where development has been prohibited, and boasted that those who told him it was impossible to get around the water laws, would soon be shocked at what he accomplished. He has been conspiring with various city employees in overriding the Planning Dept. while plat/parcel maps are altered at title companies to reflect the illegal changes to property lines. This explains the mystery of why Fresno is the shambles it is - it is also why there are no older records.

Reporting this to the City of Fresno resulted in great panic - they went as far as to have a Restraining Order issued against me in order to keep this covered up. Kerry Trost (sr risk analyst) has the audacity to call ME a "liar" about the city's own (unaltered) records, which verify exactly what is taking place! Add perjury.The City of Fresno's equipment was setting next to my family's 3 properties for several days - they did not leave until the sewer and water lines in the alley were replaced. Unauthorized! If you cannot imagine what that entailed to the connecting properties, the evidence is all here. Additionally, one neighbor left dead (after being exposed to raw sewage, foot amputation); one never seen again; forged/fraudulent legal documents on 3 out of 4 properties; sewer/water lines switched with corroded lines now clamped together; mold, termites, new walls (trash), change of property lines, and DENIAL OF ALL! I endured ongoing illnesses and continue to suffer excruciating bouts of foot cellulites after exposure to raw sewage. Despite evidence of medical crisis, risk analyst refused to test the soil - "not her job." But LYING about the cause behind sewage back spills was? She was the last person seen speaking (lying) to my other neighbor who was never seen again. She also lied about the countless photographs taken - before, during and after. (Much more.)

What is being done with our water source?  This appears to go beyond Fresno - the public is entitled to answers; we are entitled to be safe.  We are not safe.  The City is withholding public information - massive cover-up.

]]> http://maxi326.wordpress.com/?p=31 Thu, 03 Apr 2008 12:14:43 +0000 maxi326 http://maxi326.wordpress.com/?p=31 This setting gives me a hard time.

I have gone through Tomcat 6 document about JNDI and JDBC so many times.

But I get this work by reading many forums.

I think the documents provided by tomcat is confusing and maybe out of sync. to the current version.

I am going straight to the solution.

Add this in your tomcat\conf\server.xml, the parameters are set according to your situation

<GlobalNamingResources>

    <!-- Editable user database that can also be used by

         UserDatabaseRealm to authenticate users

    -->	<Resource name="jdbc/TestDB" auth="Container" type="javax.sql.DataSource"

               maxActive="100" maxIdle="30" maxWait="10000"

               username="root" password="" driverClassName="com.mysql.jdbc.Driver"

               url="jdbc:mysql://localhost:3306/javatest?autoReconnect=true"/>

</GlobalNamingResources>

Add this to your tomcat\conf\context.xml

<ResourceLink name="jdbc/TestDB" global="jdbc/TestDB" type="javax.sql.DataSource"/>

Nothing needs to be done to you per-web web.xml.

It is not what tomcat documentation mention in server.xml <host><context>...</context></host>

Maybe that works for per-web-jndi setting but not for global one.

This look like easy setting, but it takes me lots of time.

P.S. I am newbie to tomcat, haha.

One more thing, If you are using Spring HibernateDaoSupport.

The value for jndiName for Tomcat is different from other like JBoss.

JBoss : java:jdbc/TestSpring

Tomcat: java:comp/env/jdbc/TestSpring

that is

<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
        <property name="jndiName">
            <value>java:comp/env/jdbc/TestSpring</value>
        </property>
    </bean>

Ho finalmente capito il significato dei parametri di configurazione di DBCP!
I miei dubbi riguardavano in particolare i parametri minIdle, maxIdle e maxActive.

Le connessioni aperte in un dato istante possono potenzialmente essere comprese tra zero e maxActive.

Quando il n. di connessioni aperte e' compreso tra maxIdle e maxActive, tutte le connessioni ritornate al pool saranno immediatamente chiuse dal pool.

Quando il n. di connessioni aperte e' compreso tra minIdle e maxIdle, tutte le connessioni ritornate al pool saranno soggette all'eventuale evictor (che si attiva con la prop timeBetweenEvictionRunsMillis). Questo significa che quando l'evictor parte, chiudera' tutte le connessioni in eccedenza (rispetto a minIdle), ovviamente secondo le impostazioni dei parametri numTestsPerEvictionRun e minEvictableIdleTimeMillis (quest'ultima in particolare indica quando tempo una connessione 'in eccesso' puo' rimanere idle nel pool prima di essere considerata 'chiudibile' dall'evictor thread).

Quando il n. di connessioni aperte e' compreso tra zero e minIdle, tutte le connessioni ritornate al pool saranno lasciate nel pool. In altre parole non si dovrebbe mai scendere al di sotto di minIdle connessioni aperte verso il db.

Ora, magari questo puo' sembrare scontato a voi, ma a me no! DBCP ha una documentazione piuttosto fumosa, e in particolare faccio ancora fatica a capire la differenza tra i vari parametri di configurazione... per esempio, cosa si intende per abandonedConnection? E come si distingue da una normale connessione idle?

Comunque intanto mi godo il mio a-ha! moment :)