Return-Path: 
 <cocoon-dev-return-29884-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 16980 invoked by uid 500); 29 Jul 2002 18:56:16 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 16932 invoked from network); 29 Jul 2002 18:56:15 -0000
Reply-To: <bloritsch@apache.org>
From: "Berin Loritsch" <bloritsch@apache.org>
To: <cocoon-dev@xml.apache.org>
Subject: RE: Performance problem XSP after April 20
Date: Mon, 29 Jul 2002 14:55:55 -0400
Message-ID: <006a01c23731$922b4670$ac00a8c0@Gabriel>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <029d01c23730$d0673da0$0a00a8c0@vgritsenkopc>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net] 
> 
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > 
> > Even better would be to start migrating to Fortress.
> > All your expensive stuff on the backend is done asyncronously,
> > so the critical path is not affected.
> > 
> > Another one would be to fix the assumption that lookup/release
> > is 0 time.  That is obviously proven false in this case.
> > 
> > The fact that the cache has to lookup and release up to 15
> > components at runtime is horrendous.  That makes me think
> > that the cache should be redesigned so that it is self contained.
> 
> Berin,
> 
> Not cache. Cocoon engine:
> 
> 1. Cocoon lookups sitemap processor.
> 2. Processor (sitemap) lookups pipelines.
> 3. Sitemap selects all matchers, selectors, actions, generators,
> serializers, transformers as needed (you have to build pipeline).
> 4. Pipeline [gets cached response and] lookups XML deserializer.
> 
> The more complex sitemap you have (more matchers/selectors/etc), the
> more lookups will happen. Say, every cocoon source will 
> lookup processor
> and continue the process from step 2.


I see.  I misread your post.


> <flame-bait>
> I know that you want to use pre-built pipelines, but (skipping
> discussion of how this could be possible) with growing site complexity
> amount of all possible pipelines in the sitemap grows exponentially
> (IIRC, DNA has only four building blocks, but amount of possible
> combinations is close to infinity), thus making any effort to 
> pre-built
> pipelines ahead of time futile.
> </flame-bait>
> 
> ;)

I wasn't addressing that at the moment.


Fortress will help tremendously.  We just need a RoleManager that can
read
the old style of XXXX.roles file, and a Fortress Container decendant
that
can read the old style of XXXX.xconf files.  They are very similar, and
Fortress is really what you guys need.


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org