tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Stevens <>
Subject Re: [T4] Three things
Date Thu, 07 Jun 2001 18:06:50 GMT
on 6/7/01 8:35 AM, "Remy Maucherat" <> wrote:

> Champagne !
> The new based build is much easier :)

Yes. Much much much easier. However, it still has dependencies on a
bazillion things which is a pain to setup, but I can manage that. :-)

> I don't really know what you're doing there (but I think I'll look at the
> source
> code ;))

What is happening in that log message is that a "Service" (which is a class
that is loaded through Class.forName() and then held onto and made into a
singleton) is instantiated and its init() methods are called.

The log message that I showed is one Service reporting that it is finished,
a delay of about 6 seconds and then another Service starting up. Services
that report (late) startup are Services which are only instantiated when
they are requested from the ServiceBroker instead of being instantiated
right away (ie: different forms of init()).

Now, the nearly impossible thing to debug (without stepping through a LOT of
code) is what is happening between the time that the one (late) Service
reports as being finished and the next one starts. It could be code in
Scarab or Turbine or Tomcat that is being executed and could be causing the

However, before the speed fix, there was about 3-4 places where there were
~10 second delays and this was repeatable. Now, after the speed fix, there
is only one ~6 second delay.

It is pretty clear to me that the original delays were somewhere in Tomcat
and not in Turbine or Scarab. Figuring out where this one last delay is is
going to be a real pain in the ass.

My guess is that because the other delays were in Tomcat, this last one is
still in Tomcat somewhere and hence my bringing it up.

> If you're loading tons of classes or something like that, static resource
> access
> (at least the initial access) can be a bit slow right now. If you look at the
> implementation, it's because of a largely innefficient reuse of the attributes
> base classes from the JNDI base package. That can be fixed easily, and would
> get
> the performance back to about the same as the direct FS access.

The faster the better. I don't think we are loading a ton of classes though.
Not more than about a hundred at startup...


View raw message