bug in XSLT proccessing (using Xalan) with more than one thread

[Szymanski Jakub <sz...@yahoo.com>]

Hello!

We use Cocoon 1.7.1 only as a XML/XSL rendering
engine.
In fact we are even not so interested in all this "new
kind of ASP/PHP3/../OWS" functionality. Our
architecture is based on service logic in part which
generates XML, and XSL is only presentation layer and
less logic is in it more we are happy. So we use
Cocoon to render dynamic XML to HTML/DHTML/WML. 

First we used JRun and servlet chaining, now we use
WebLogic and CocoonRequest. We experience serious
problem in case of extensive usage of Cocoon by more
users. It seems that Cocoon is not thread-safe - can
not be used in the same time by more than one user. It
comes from Xalan and Cocoon architecture. In Xalan
docs one can find:
"Xalan is thread-safe for one instance per thread. If
you are using the same instance of XSLTProcessor to
perform more than one transformation, call the reset
method between transformations"

So there are two methods to provide multithreading
changing XalanTransformer.java:
part which cause problem is:

    public Document transform(Document in, String
inBase, Document sheet, String sheetBase, Document
out) throws Exception {
        XSLTInputSource i = new XSLTInputSource(in);
        // inBase not used for now (external entities
are already included at parse time)
        XSLTInputSource s = new
XSLTInputSource(sheet);
        s.setSystemId(sheetBase);
        XSLTResultTarget o = new
XSLTResultTarget(out);
        processor.process(i, s, o);
        return out;
    }

As you see it is possible for two (and more) thread to
call processor.process(i, s, o) in the same time which
is not valid for Xalan.

Solutions are
- use pool of processors
- use synchronization of this block

First is of course far better.

Am I right in my conclusions or I did some mistakes in
analyzing Cocoon problem with threads ?

Please help us to solve this problem. It is really
impossible to use Cocoon in real live in such
situation.


One more remarks about cache mechanisms and Cocoon2.
As I said for us Cocoon is (will be) great component
to render XML/XSLT. To be successful it should:
- easily be used with dynamic XML
- be really fast (using advanced XSL cache even with
  precomplation of it - Xalan feature)

Rest of it features are not so important but will be
nice to have:
- easy way to add new presentation layer (new static
XSL docs) without changing dynamic part of system
which generates XML. Now it is not possible because
one has to specify media XSL document in XML header.
Has anybody idea how to do it? Is it what will be
useful not only for us ?


Cheers,

Jakub Szymanski


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Re: bug in XSLT proccessing (using Xalan) with more than one thread

[Stefano Mazzocchi <st...@apache.org>]

Szymanski Jakub wrote:
> 
> Hello!
> 
> We use Cocoon 1.7.1 only as a XML/XSL rendering
> engine.

It seems you do not. check your Cocoon version again.

> In fact we are even not so interested in all this "new
> kind of ASP/PHP3/../OWS" functionality. Our
> architecture is based on service logic in part which
> generates XML, and XSL is only presentation layer and
> less logic is in it more we are happy. So we use
> Cocoon to render dynamic XML to HTML/DHTML/WML.
> 
> First we used JRun and servlet chaining, now we use
> WebLogic and CocoonRequest. We experience serious
> problem in case of extensive usage of Cocoon by more
> users. It seems that Cocoon is not thread-safe - can
> not be used in the same time by more than one user. It
> comes from Xalan and Cocoon architecture. In Xalan
> docs one can find:
> "Xalan is thread-safe for one instance per thread. If
> you are using the same instance of XSLTProcessor to
> perform more than one transformation, call the reset
> method between transformations"
> 
> So there are two methods to provide multithreading
> changing XalanTransformer.java:
> part which cause problem is:
> 
>     public Document transform(Document in, String
> inBase, Document sheet, String sheetBase, Document
> out) throws Exception {
>         XSLTInputSource i = new XSLTInputSource(in);
>         // inBase not used for now (external entities
> are already included at parse time)
>         XSLTInputSource s = new
> XSLTInputSource(sheet);
>         s.setSystemId(sheetBase);
>         XSLTResultTarget o = new
> XSLTResultTarget(out);
>         processor.process(i, s, o);
>         return out;
>     }
> 
> As you see it is possible for two (and more) thread to
> call processor.process(i, s, o) in the same time which
> is not valid for Xalan.
> 
> Solutions are
> - use pool of processors
> - use synchronization of this block
> 
> First is of course far better.
> 
> Am I right in my conclusions or I did some mistakes in
> analyzing Cocoon problem with threads ?

This has already been fixed in the CVS.

> Please help us to solve this problem. It is really
> impossible to use Cocoon in real live in such
> situation.

upgrade to Cocoon 1.7.1-dev 

> One more remarks about cache mechanisms and Cocoon2.
> As I said for us Cocoon is (will be) great component
> to render XML/XSLT. To be successful it should:
> - easily be used with dynamic XML
> - be really fast (using advanced XSL cache even with
>   precomplation of it - Xalan feature)

of course.
 
> Rest of it features are not so important but will be
> nice to have:
> - easy way to add new presentation layer (new static
> XSL docs) without changing dynamic part of system
> which generates XML. Now it is not possible because
> one has to specify media XSL document in XML header.
> Has anybody idea how to do it? Is it what will be
> useful not only for us ?

The cocoon2 sitemap allows you to do exactly this.

Be happy, all your concerns are already solved ;-)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------