cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject AW: Strange problems with concurrent access of Xalan-2.0.0
Date Mon, 19 Feb 2001 13:57:28 GMT
> Scott Boag wrote:
>> Any guesses from the Xalan Team?
>I've been off sick with the flu, so I'm a bit behind this thread.  As far
>as we know the Templates objects are safe among concurent threads.  The
>easiest way to reproduce threading problems may be to use a multi-processor
>> A thread might finish first, resetting the template and the other
>> thread still try to use it.
>What do you mean by "resetting the template"?

After looking for some time into the Xalan-J 2.0.0 code, I think that the
reset() method on the TransformerImpl is invoked, so resetting the m_resultTreeHandler
to null. So "resetting the template" was wrong, sorry for this wrong hint.

>> java.lang.NullPointerException
>> at org.apache.xalan.templates.ElemCopy.execute(
>The value that is failing here is obtained from the Transformer.  As Myriam
>asked, is there any chance a Transformer is being used across threads?

What we suspect after our research is, that the TransformerImpl (or some other object
below the TransformerImpl) is creating a thread which hasn't finished its work
when the main thread finishes - which means leaves the transform(Source source) method.
The finally clause of the transform method invokes the reset() method.
Is it possible, that in some circumstances the main thread does not wait for his child
threads to finish.

We use the Xalan-J inside the Cocoon2 servlet environment. It seams that the problem only
arises when frames are used, so upto 4 threads are created simultaniously. 
For each Cocoon2-Thread a new Transformer instance is created.

Although I indicated in the first mail that the problem only occurs with Xalan-Stylesheet-Storing
turned on in Cocoon2, this is not true. We had some rare cases where the problem arise without
storing turned on.


View raw message