cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Szymon Stasik <szymon.sta...@efigence.com>
Subject Re: Threadsafe ServerPages (was Re: esql thread unsafe - bug)
Date Wed, 20 Feb 2002 10:07:59 GMT


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


Mime
View raw message