On Tue, 19 Feb 2002, Szymon Stasik wrote:
> Hi,
>
> I've discovered serious bug in esql logicsheet while using it with
> cocoon-1.8.3. However the same bug seems to exists in cocoon2. The
> problem is that while node stack logic variables (xspParentNode,
> xspCurrentNode, xspNodeStack) are defined inside populateDocument
> method, similar objects used by esql (_esql_connections etc...) exist as
> object attributes.
>
> Since there is only one instance of particular xsp page (eg.
> _index.class) per application, under havy load it is possible (and easy
> to observe using eg jmeter) that concurent calls to the same
> _index.populateDocument method will lead esql structures and connection
> pools to be corrupted.
>
> you can find attached the patch that should fix thing up (it works at
> least with cocoon-1.8.x)
This should only be the case if ServerPages were marked ThreadSafe but
they are marked Poolable. I'm not very familiar with the Cocoon1 codebase
anymore and cannot remember the implemtation of the ServerPages. Are you
sure they are handled threadsafe in Cocoon1?
But this leads me do a question guys...
...is it really necessary ServerPages are marked Poolable??
This could explain be one issue why Cocoon1 seems to scale better than
Cocoon2!!
So we have 3 options:
* do not mark them at all. (as for actions) let the writer decide if they
are poolable or threadsafe.
Problem: - how to mark them?
- current logicsheets are not prepared to handle as threadsafe
- the AbstractServerPages has a couple of setters from
AbstractXMLProducer which prevents beeing theadsafe
* mark them threadsafe
Problem: - current logicsheets are not prepared to handle as threadsafe
- the AbstractServerPages has a couple of setters from
AbstractXMLProducer which prevents beeing theadsafe
* keep them as they are
Problem: - if Cocoon1 serverpages are *really* threadsafe Cocoon1 will
always have a vantage over Cocoon2 in terms of scaleability
So what to do...
...AFAICS there is no way making the ServerPages threadsafe as long as we
use the AbstractXMLProducer pattern. Find an alternative would be really a
major change....
What do guys think?
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
