Threadsafe ServerPages (was Re: esql thread unsafe - bug)

[Torsten Curdt <tc...@dff.st>]

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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Threadsafe ServerPages (was Re: esql thread unsafe - bug)

[Szymon Stasik <sz...@efigence.com>]

Torsten Curdt wrote:
>>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?

It has to work as thread safe with cocoon1 since this was a serious 
problem even on medium load.


> 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!!

propably this is some reason. IMHO it is a good idea to give a choice to 
a writer. Or maybe better it should be some parameter/method through all 
code and all taglibs - if any part of code can break thread safety then 
some method should return false or some taglib will define some code to 
mark it.

Szymon


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