Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <3F0D2367.5040908@mail.more.net>
Date: Thu, 10 Jul 2003 03:27:19 -0500
From: Glenn Nielsen <glenn@mail.more.net>
Organization: MOREnet
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030224
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: [4.1.25] Tag today
References: <20030710075729.80303.qmail@web9501.mail.yahoo.com>
In-Reply-To: <20030710075729.80303.qmail@web9501.mail.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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 traces where two thirds of the
threads are waiting on the same synchronization bottleneck
related to use of one or more of the following classes:

java.util.Date
java.util.TimcZone.getDefault()
java.util.Calendar.getInstance()
java.text.SimpleDateFormat
java.sql.Date
java.sql.Time
java.sql.Timestamp

They all hit the same synchronization bottleneck.  And I have
multiple code bases that have to go through this bottleneck;
Tomcats FileLogger which gets used a great deal for the Connector
log when Tomcat is heavily loaded, the MySQL Connector/J JDBC driver,
and I have customer web application code which hits this also.

Due to scaling problems I setup a second app server and load balancing.
It still did not scale well because of the above synchronization
bottleneck.  Both app servers became overloaded due to this bottleneck.

I now think the best solution might be a commons project
to provide alternate solutions for the above date related classes
designed so that this synchronization bottleneck is avoided.

Regards,

Glenn


Remy Maucherat wrote:
> 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 to fix two security
> issues primarily, and must be voted stable. As a
> result, there will not be any more delays in this tag
> (which should have happened yesterday, but
> unfortunately, my DSL decided to die on me late in the
> evening as I was putting together the changelog).
> This is a good optimization overall, that can be done
> in a few components (like the access log), but there's
> simply no incentive to push back a release for it.
> I'll have all the time I want for Tomcat starting next
> week, so I can start doing more frequent TC 4
> releases, instead of focusing the small amount of time
> I have on TC 5 :-D
> 
> Additionally, there is no critical path component in
> Tomcat which needs to be optimized for Date processing
> (and esp not Jasper, except in dev mode). I did that
> long ago.
> 
> R�my
> 
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org