Glenn,
This is quite interesting. How many concurrent threads need to be
running before this bottleneck starts to become a significant issue?
Does a simple test case which simply starts up a number of threads which
all use one of the classes shown below display the problem nicely?
I'd guess that
Glenn,
What you've posted does not make much sense to me:
logging is not a per request event, or at least it
should not, so I don't see any bottleneck in a normal
situation where logged events are relatively rare.
The change is too big to be included at the last
minute in 4.1.25, which is meant t
Remy,
It can wait, go ahead with the release.
But the FileLogger's use of java.sql.Timestamp is a bottleneck,
I have the thread dump stack traces to prove that it is.
Right now the biggest problem I have with Tomcat scaling
is with this type of synchronization bottleneck.
I have thread dump stack
Remy,
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
Tim Funk wrote:
For 4.1.25 - I added the AccessLogValve/ExtendedAccessLogValve ports
(from 5), but never updated the RELEASE-NOTES-4.1.txt
[4.1.25] #20380
AccessLogValve incorrectly calculates timezone
[4.1.25] #16374
AccessLogValve Date in file name configurable
[4.1.25] #16400
For 4.1.25 - I added the AccessLogValve/ExtendedAccessLogValve ports (from
5), but never updated the RELEASE-NOTES-4.1.txt
[4.1.25] #20380
AccessLogValve incorrectly calculates timezone
[4.1.25] #16374
AccessLogValve Date in file name configurable
[4.1.25] #16400
Access
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
