This could be a reasonable explanation for the scalability problem.
Isn't this a problem with all generators? In Cocoon 1 the following method
generates the output of an XSP page:
public void populateDocument(
HttpServletRequest request,
HttpServletResponse response,
Document document
}
>From what I understand from C2, producers and consumers are handled the
same, ie. not threadsafe. I think producers/generators could be handled
different (threadsafe) because they only feed the pipeline. How is this
handled with sources?
This would mean a lot of work because the generate() method should look like
generate(ObjectModel, Consumer).
Could this kind of problem be handled if we migrate generators to the
concept of sources and make it easier to build sources?
I fear I am still far from understanding the C2 implementation completely,
so I hope this makes sense.
Michael
> -----Original Message-----
> From: Torsten Curdt [mailto:[EMAIL PROTECTED]]
> Sent: woensdag 20 februari 2002 10:45
> To: [EMAIL PROTECTED]
> Subject: Threadsafe ServerPages (was Re: esql thread unsafe - bug)
>
>
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
