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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
