Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Subject: Re: SoC between flow and sitemap
From: Bruno Dumon <bruno@outerthought.org>
To: cocoon-dev@xml.apache.org
In-Reply-To: <babqtm$tcl$1@main.gmane.org>
References: <ba41ln$v68$1@main.gmane.org>
	 <LKENJPKDAIKAPKHEOCMMEEAMDKAA.cziegeler@s-und-n.de>
	 <ba8cfs$m9t$1@main.gmane.org> <3EC800C3.3040901@anyware-tech.com>
	 <bab1pj$sa3$1@main.gmane.org> <3EC924F4.1010605@anyware-tech.com>
	 <3EC9357F.6090104@outerthought.org>  <3EC94C98.8020607@anyware-tech.com>
	 <1053383930.29893.7.camel@yum.ot>  <babqtm$tcl$1@main.gmane.org>
Content-Type: text/plain
Organization: Outerthought
Message-Id: <1053416904.4683.20.camel@yum.ot>
Mime-Version: 1.0
Date: 20 May 2003 09:48:24 +0200
Content-Transfer-Encoding: 7bit

On Tue, 2003-05-20 at 01:57, Stefano Mazzocchi wrote:
> on 5/19/03 5:39 PM Bruno Dumon wrote:
> 
> > On Mon, 2003-05-19 at 23:28, Sylvain Wallez wrote:
> > [...]
> > 
> >>Yes, but you have to consider how this is actually implemented. If you 
> >>put a farm of Tomcats behind an httpd with mod_jk, you will be 
> >>guaranteed that requests for a given session will always be handled by 
> >>the same Tomcat instance. This is called session affinity. But Tomcats 
> >>don't communicate with each others to exchange session or application data.
> >>
> >>This means that if a continuation ContA is created on Tomcat TC1, all 
> >>subsequent requests referencing this continuation must be handled by the 
> >>same TC1, and not TC2, since ContA doesn't exist on TC2. And the only 
> >>means you have to achieve this if servlet engines don't communicate is 
> >>through session affinity.
> >>
> >>So continuations must be bound to sessions.
> >>
> > 
> > 
> > Actually mod_jk only looks at a suffix appended to the session cookie,
> > and it shouldn't be too difficult to hack mod_jk to use a different
> > cookie especially for this purpose. So sessions are not really required
> > for this.
> 
> What about BEA weblogic, IBM webshere, Oracle appserver, etc, etc, etc?
> 
> Hypothetical chat between a CTO and a cocoon proponent:
> 
>  - cocoon? we are interested at it, but is it fast?
>  - the pipeline creation is very complex and can be much slower than
> text-based tecnologies, but cocoon has a very good caching mechanism
> that allows to reuse all possible content and provide your own caching
> logic to components if you need to. The results in real life prove
> cocoon to be highly efficient. In a highly critical environment (which I
> can't name), the use of cocoon proved to be orders of magnitude faster
> than a rival application based on Oracle Internet File System.
> 
>  - what about static stuff? cocoon is much slower than a web server!
>  - yes, but I normally suggest to put a transparent proxy up front and
> cocoon will serve static content only once, the remaining it done by the
> proxy lightning fast. (it is also transparent if you have dynamically
> generated resources like images, flash files or CSS stylesheets and
> allows to maintain all your URI space in one comfortable location)
> 
>  - hmmm, ok, but does it scale for dynamic stuff?
>  - sure, for a stateless cocoon environment, you can throw silicon at it
> and balance the load transparently by replicating the cocoon environment
> on different machines. A european company (which I can't name) did tests
> that showed 12000 req/sec on a big clustered environment.
> 
>  - cool, but what about stateful cases, expecially with the flow and
> this new continuation thing, does it scale?
>  - only with tomcat and mod_jk
> 
>  - ok, we'll use struts then.

I wasn't serious about doing it this way, but I found the way Sylvain
described it, it was as if some magic was happening, and that it was
session related. mod_jk just happens to reuse the session cookie for
this purpose, but it could have used any other cookie as well.

And a lot of the commercial loadbalancing solutions (exactly the type of
things that weblogic or websphere buyers will be using) actually require
you to set a cookie especially for this purpose.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org