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.
Regards,
Glenn
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
