Hi
>>
No, but Berin will do some changes in the excalibur framework. In near
future there will be a "resource cache" which will fix this problem. See
Berins answers
to this thread.
<<
I found his answer. Is there any workaround (or way to reduce this) until
this is in place?
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [[EMAIL PROTECTED] - http://www.sundn.de]
=================================================================
-----Ursprüngliche Nachricht-----
Von: Gerhard Froehlich [mailto:[EMAIL PROTECTED]]
Gesendet: Montag, 27. August 2001 12:31
An: [EMAIL PROTECTED]
Betreff: Re: AW: IT'S TIME TO REDO YOUR TESTS, GENTLEMEN!
Hi Mathew
> >>
> According to my tracing tool (OptimizeIT) most of the cpu time was
> consumed
> by the method java.util.ZipFile.open(). As I traced down the thread
> the first "core" method from cocoon I hit in this tree of method
> invocations
> was the process() method of the CachingPipline. Ok that's plausibly of
> course.
> <<
>
> I have (also) been doing some testing with OptimizeIT and because I have
> the
> same results (i.e. ZipFile.open() using up the cpu time) - has this been
> fixed with last weeks patches or do we need to look at this again?
>
> >From my tests it looks as though the calls are coming from the DTMManager
> (see screen-shot) which would seem to point to xalan.
No, but Berin will do some changes in the excalibur framework. In near
future there
will be a "resource cache" which will fix this problem. See Berins answers
to
this thread.
Cheers
Gerhard
--
Gerhard Fröhlich
[EMAIL PROTECTED]
"black holes are,
when GOD is dividing by zero"
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
