Tomcat Maven Plugin and Apache Tomcat post 6.0.29

Last Updated on Mercredi, 21 mars 2012 08:36 Written by Henri Gomez Vendredi, 11 mars 2011 12:56

If you’re using the Tomcat Maven Plugin and want to use post 6.0.29  Apache Tomcat, ie latest 6.0.32, you should update your pom to handle a change in artifact.

Up to 6.0.29, Eclipse JDT compiler was bundled as jasper-jdt :

<dependency>
              <groupId>org.apache.tomcat</groupId>
              <artifactId>jasper-jdt</artifactId>
              <version>6.0.29</version>
            </dependency>

With 6.0.30, Apache Tomcat team started to bundle Eclipse JDT directly:

<dependency>
  <groupId>org.eclipse.jdt.core.compiler</groupId>
  <artifactId>ecj</artifactId>
  <version>3.5.1</version>
</dependency>

As consequence, org.apache.tomcat/jasper-jdt artifact didn’t exist anymore after release 6.0.29.

Jasper JDT up to 6.0.29

Jasper JDT up to 6.0.29

For Tomcat Maven Plugin, you should update the suggested pom like this :

    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>tomcat-maven-plugin</artifactId>
                    <version>1.2-SNAPSHOT</version>
                    <dependencies>
                        <dependency>
                            <groupId>org.apache.tomcat</groupId>
                            <artifactId>catalina</artifactId>
                            <version>${tomcat.version}</version>
                        </dependency>
                        <dependency>
                            <groupId>org.apache.tomcat</groupId>
                            <artifactId>catalina-ha</artifactId>
                            <version>${tomcat.version}</version>
                            <scope>runtime</scope>
                        </dependency>
                        <dependency>
                            <groupId>org.apache.tomcat</groupId>
                            <artifactId>tribes</artifactId>
                            <version>${tomcat.version}</version>
                            <scope>runtime</scope>
                        </dependency>
                        <dependency>
                            <groupId>org.apache.tomcat</groupId>
                            <artifactId>el-api</artifactId>
                            <version>${tomcat.version}</version>
                            <scope>runtime</scope>
                        </dependency>
                        <dependency>
                            <groupId>org.apache.tomcat</groupId>
                            <artifactId>jasper</artifactId>
                            <version>${tomcat.version}</version>
                            <scope>runtime</scope>
                        </dependency>
                        <dependency>
                            <groupId>org.apache.tomcat</groupId>
                            <artifactId>jasper-el</artifactId>
                            <version>${tomcat.version}</version>
                            <scope>runtime</scope>
                        </dependency>
                        <dependency>
                            <groupId>org.eclipse.jdt.core.compiler</groupId>
                            <artifactId>ecj</artifactId>
                            <version>3.5.1</version>
                            <scope>runtime</scope>
                        </dependency>
                        <dependency>
                            <groupId>org.apache.tomcat</groupId>
                            <artifactId>jsp-api</artifactId>
                            <version>${tomcat.version}</version>
                            <scope>runtime</scope>
                        </dependency>
                        <dependency>
                            <groupId>org.apache.tomcat</groupId>
                            <artifactId>servlet-api</artifactId>
                            <version>${tomcat.version}</version>
                            <scope>runtime</scope>
                        </dependency>
                        <dependency>
                            <groupId>org.apache.tomcat</groupId>
                            <artifactId>coyote</artifactId>
                            <version>${tomcat.version}</version>
                            <scope>runtime</scope>
                        </dependency>
                        <dependency>
                            <groupId>org.apache.tomcat</groupId>
                            <artifactId>dbcp</artifactId>
                            <version>${tomcat.version}</version>
                            <scope>runtime</scope>
                        </dependency>
                    </dependencies>
                </plugin>
            </plugins>
        </pluginManagement>

Notice: An updated version of Tomcat Maven Plugin 1.2-SNAPSHOT has been released, this hack is no more necessary

Learn More

OS/X – OpenJDK 6 vs Apple JDK 6

Last Updated on Lundi, 8 novembre 2010 11:58 Written by Henri Gomez Lundi, 8 novembre 2010 12:34

From finished building OpenJDK 6 on OS / X Snowleopard, I wanted to test just to see how he behaved towards the implementation of Apple.
I used a development version of MacPorts (see it trac) that appears very promising and got OpenJDK 1.6.0-b20.


openjdk version "1.6.0"
OpenJDK Runtime Environment (build 1.6.0-b20)
OpenJDK 64-Bit Server VM (build 17.0-b16, mixed mode)

A Java application with GUI under OS/X – OpenJDK

First test was to launched a big application like Eclipse under OS/X with OpenJDK.
I selected OpenJDK 6 as default VM by adding the properties file in this eclipse.ini Eclipse.app / Contents / MacOS / eclipse.ini


-vm
/opt/local/share/java/openjdk6/bin/java

It worked pretty well :

A big thank you to SWT / Cocoa since there are still problems with AWT and OS / X

Speed and stability of OpenJDK

My test system is an Apple Mac Book Pro (MacBookPro5,1) with Intel Core 2 Duo 2.66Ghz and 4Gb DDR3 1067Mhz.

DaCapo Benchmarks

I do some tests with DaCapo 9.12-bach, discarding batik test, this one requiring a working AWT/Swing support .

Bench tests launched with -n X, ie (java -jar dacapo-9.12-bach.jar -n 10 pmd)

BenchApple JDK6OpenJDK 6
avrora (10 iterations)5247ms4980ms
eclipse (2 iterations)53292ms34404ms
fop (10 iterations)560ms408ms
h2 (2 iterations)Failure (pending test)6488ms
jython (2 iterations)6034msFailure (Trace/BPT trap)
luindex (10 iterations)1072ms990ms
lusearch (10 iterations)5997ms3957ms
pmd (10 iterations)3067ms2890ms
sunflow (10 iterations)6998ms6442ms
tomcat (5 iterations)4108msFailure (connection reset)
tradebeans (5 iterations)8257msFailure (connection reset)
tradesoap (5 iterations)20472ms12378ms
xalan (10 iterations)2877ms2847ms

Some tests failed under OpenJDK 6, related on Tomcat / IO but as we can see in next section, Tomcat 6 or 7 worked with OpenJDK.

IO Benchs with ApacheBench and Tomcat6/7

Then I wanted to see the speed of the JVM under IO load and why I made a little stress test two well-known applications, Tomcat 6 and 7.
I used ApacheBench to request 1000000 time a simple URI (/examples/servlets/servlet/RequestInfoExample), with 100 concurrents clients.

ApacheBench and Tomcat were on the same machine, to avoid network bottleneck.
Activity Monitor show a CPU load of 120% for Java and 20% for ab

Here also OpenJDK 6 perform well even slighty better than Apple own implementation.

TomcatApple JDK 6Open JDK 6
6.0.2915852 req/s16011 req/s
7.0.4beta13700 req/s14212 req/s

Apache 6.0.29 / Open JDK 6

Server Software: Apache-Coyote/1.1
Server Hostname: localhost
Server Port: 8080

Document Path: /examples/servlets/servlet/RequestInfoExample
Document Length: 715 bytes

Concurrency Level: 100
Time taken for tests: 62.456 seconds
Complete requests: 1000000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 1000000
Total transferred: 868001736 bytes
HTML transferred: 715001430 bytes
Requests per second: 16011.35 [#/sec] (mean)
Time per request: 6.246 [ms] (mean)
Time per request: 0.062 [ms] (mean, across all concurrent requests)
Transfer rate: 13572.15 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 3
Processing: 0 6 3.1 6 123
Waiting: 0 6 3.1 6 123
Total: 0 6 3.1 6 123

Percentage of the requests served within a certain time (ms)
50% 6
66% 6
75% 7
80% 8
90% 9
95% 11
98% 13
99% 15
100% 123 (longest request)

Apache 7.0.4beta / Open JDK 6

Server Software: Apache-Coyote/1.1
Server Hostname: localhost
Server Port: 8080

Document Path: /examples/servlets/servlet/RequestInfoExample
Document Length: 683 bytes

Concurrency Level: 100
Time taken for tests: 70.360 seconds
Complete requests: 1000000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 1000000
Total transferred: 855000855 bytes
HTML transferred: 683000683 bytes
Requests per second: 14212.64 [#/sec] (mean)
Time per request: 7.036 [ms] (mean)
Time per request: 0.070 [ms] (mean, across all concurrent requests)
Transfer rate: 11867.01 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 3
Processing: 0 7 6.6 6 379
Waiting: 0 7 6.6 6 379
Total: 0 7 6.6 6 379

Percentage of the requests served within a certain time (ms)
50% 6
66% 7
75% 8
80% 9
90% 11
95% 12
98% 14
99% 15
100% 379 (longest request)

Apache 6.0.29 / Apple JDK 6

Server Software: Apache-Coyote/1.1
Server Hostname: localhost
Server Port: 8080

Document Path: /examples/servlets/servlet/RequestInfoExample
Document Length: 715 bytes

Concurrency Level: 100
Time taken for tests: 63.082 seconds
Complete requests: 1000000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 1000000
Total transferred: 868005208 bytes
HTML transferred: 715004290 bytes
Requests per second: 15852.36 [#/sec] (mean)
Time per request: 6.308 [ms] (mean)
Time per request: 0.063 [ms] (mean, across all concurrent requests)
Transfer rate: 13437.43 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 4
Processing: 0 6 3.0 6 125
Waiting: 0 6 3.0 6 125
Total: 0 6 3.0 6 125

Percentage of the requests served within a certain time (ms)
50% 6
66% 6
75% 7
80% 7
90% 9
95% 11
98% 13
99% 15
100% 125 (longest request)

Apache 7.0.4beta / Apple JDK 6

Server Software: Apache-Coyote/1.1
Server Hostname: localhost
Server Port: 8080

Document Path: /examples/servlets/servlet/RequestInfoExample
Document Length: 683 bytes

Concurrency Level: 100
Time taken for tests: 72.992 seconds
Complete requests: 1000000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 1000000
Total transferred: 855067545 bytes
HTML transferred: 683053957 bytes
Requests per second: 13700.05 [#/sec] (mean)
Time per request: 7.299 [ms] (mean)
Time per request: 0.073 [ms] (mean, across all concurrent requests)
Transfer rate: 11439.91 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 6
Processing: 0 7 8.7 7 770
Waiting: 0 7 8.7 7 770
Total: 0 7 8.7 7 770

Percentage of the requests served within a certain time (ms)
50% 7
66% 8
75% 8
80% 9
90% 11
95% 12
98% 14
99% 16
100% 770 (longest request)

Conclusion

OpenJDK 6 appears very promising and Apple’s decision to suspend the maintenance of Java on its next OS / X will not be so bad.

Hoping now that porting AWT / Swing and Cocoa to appear quickly in the Project OpenJDK / BSD

Learn More

Désactiver le contrôle de fuite mémoire dans Tomcat 6.0.26+

Last Updated on Vendredi, 30 juillet 2010 06:46 Written by Henri Gomez Mardi, 4 mai 2010 03:38

Si vous êtes passé à Tomcat 6.0.26, vous avez pu observer ce genre de message dans vos logs :

4 mai 2010 17:08:46 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [Thread-8] but has failed to stop it. This is very likely to create a memory leak.

Ou encore :

4 mai 2010 15:47:09 org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
SEVERE: A web application registered the JBDC driver [com.ibm.as400.access.AS400JDBCDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.

Ces messages proviennent d’un nouveau composant, le JreMemoryLeakPreventionListener qui surveille l’activité des threads et pilotes JDBC crées par vos applications web au moment du déchargement d’une webapp.

Il est activé par défaut et se trouve dans le fichier server.xml présent dans le répertoire conf de votre installation Tomcat.


  &amp;amp;lt;!-- Prevent memory leaks due to use of particular java/javax APIs--&amp;amp;gt;
  &amp;amp;lt;Listener className=&amp;amp;quot;org.apache.catalina.core.JreMemoryLeakPreventionListener&amp;amp;quot; /&amp;amp;gt;

Même s’il n’est pas recommandé de désactiver ce contrôle, qui vous permet de tracer des fuites mémoire, vous pouvez revenir à la situation précédente sans ‘surveillance’ en commentant la ligne Listener.

Learn More
Designed by RocketTheme
WordPress is Free Software released under the GNU/GPL License.