tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <>
Subject Re: [4.1.25] Tag today
Date Thu, 10 Jul 2003 07:27:21 GMT

I just discovered a nasty synchronization bottlneck in
org.apache.catalina.logger.FileLogger in its use of java.sql.Timestamp.
The actual synchronization bottleneck is in java.util.Date which
java.sql.Timestamp extends.

I am pretty sure I have found a work around to avoid the synchronization.
The work around will involve use of a static instance of the default TimeZone
(TimeZone.getDefault() has a synchronization bottleneck)
and replacement of java.sql.Timestamp with a java.util.Calendar object
with is thread local.

It may take me a few days before I can get this in place and do benchmark
comparisons vs the current code.

I found this when debugging scalability problems on a production Tomcat.
Many of the threads were in a bottleneck trying to instantiate or use
a java.util.Date object.  The worst offender was having the MySQL JDBC
driver return a Date object for a DATE, TIME, or TIMESTAMP field.

I found this to be a significant performance issue on a production system.
I would like to delay the Tomcat 4.1.25 release until it can be resolved.

Of course there are other places in Tomcat and supporting libraries where
java.util.Date is used and where there may be a benefit to optimizing out
the synchronization bottleneck of java.util.Date.  Such as Jasper.
This also applies to any classes which extend java.util.Date such as
java.sql.Time and java.sql.Timestamp.

BTW, I looked at the source for java 1.4.1 and the synchronization bottleneck
in java.util.TimeZone and java.utilDate still exist.



Remy Maucherat wrote:
> As discussed earlier, I plan to tag 4.1.25 later today.
> Note: I haven't ported the JSP/JSPC package path fixes, as I consider 
> them risky. I plan to port them later on, but it would be very good to 
> have this build rated as stable, without further delays, as there are a 
> couple of important fixes in it.
> Note 2: Given that my "release" computer is dead (but will be back from 
> the dead in some form maybe, given its HD should still work), there 
> could be packaging mistakes (in which case, let me know, and I will just 
> replace the bins with new ones).
> Remy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message