cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: SoC between flow and sitemap
Date Tue, 20 May 2003 06:25:44 GMT
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.

Sad, but so true.

Moreover, from a Cocoon developper point of view, we (at least I) don't 
want to write and maintain a Cocoon-specific fork of mod_jk.

So let's use what the servlet engines give us, even if that means using 
sessions which could theoretically be avoided but which are actually 
used by most web applications.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message