You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/02/15 16:47:32 UTC
Strange problems with concurrent access of Xalan-2.0.0
Hello,
since the switch from the Xalan2D07 to the Xalan-2.0.0 version in Cocoon2 we get sometimes very strange problems.
We are using frames which all four use the same stylesheets. The xalan is driven by the cocoon pipeline.
If we turn on the storing (formerly known as caching) of the TraxTransformer we get from time to time a NPE in one frame. Sometimes its even worse: One frame contains part of the content of another frame and the other frame is totally broken. Reloading the whole page brings up all frames correctly.
However if we turn off the storing we never did see this phenomenen. So we assume that this problems have something to do with the storing.
The store stores the Templates. Is it possible, that this problem can occure, when several threads use the same Template (as delivered by the store). A thread might finish first, resetting the template and the other thread still try to use it.
This is only a guess - has someone else had these problems?
As they only occur occasionally it his very hard to reproduce them...
Perhaps someone of you has a guess whats going on.
The exception we get is the following:
java.lang.NullPointerException
at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145)
at org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
Each.java:495)
at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
tes.java:193)
at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
ansformerImpl.java:2154)
at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
ansformerImpl.java:2097)
at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
sformerImpl.java:2029)
at org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
rImpl.java:1189)
at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
:2894)
This indicates that the ResultTreeHandler is not available (set to null).
As most times everything is working fine it must have to do with the parallel usage of the stylesheets.
Carsten Ziegeler
Open Source Group sunShine - Lighting up e:Business
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto:cziegeler@sundn.de
================================================================
AW: Strange problems with concurrent access of Xalan-2.0.0
Posted by Carsten Ziegeler <cz...@sundn.de>.
> 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
>system.
>
>> 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(ElemCopy.java:145)
>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.
Carsten
AW: Strange problems with concurrent access of Xalan-2.0.0
Posted by Carsten Ziegeler <cz...@sundn.de>.
> 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
>system.
>
>> 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(ElemCopy.java:145)
>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.
Carsten
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>
> Berin Loritsch wrote:
>
> > I ran accross this abnormality when I stress tested Cocoon using
> > Apache JRun.
>
> There is no such thing as "Apache JRun" :)
>
> You mean "Apache JMeter", right?
>
> I'm picky because the Allaire guys might be offended by this :) or some
> apache members as well :)
Yup, that's what I meant. I was discussing alternative J2EE architectures
to IBM WebSphere with my bosses--so my brain didn't completely switch
gears.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
> I ran accross this abnormality when I stress tested Cocoon using
> Apache JRun.
There is no such thing as "Apache JRun" :)
You mean "Apache JMeter", right?
I'm picky because the Allaire guys might be offended by this :) or some
apache members as well :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
>
> Berin Loritsch wrote:
> > Giacomo Pati wrote:
> > > Carsten Ziegeler wrote:
> > > > Hello,
> > > >
> > > > since the switch from the Xalan2D07 to the Xalan-2.0.0 version in
> > > > Cocoon2 we get sometimes very strange problems.
> > > >
> > > > We are using frames which all four use the same stylesheets. The xalan
> > > > is driven by the cocoon pipeline.
> > > >
> > > > If we turn on the storing (formerly known as caching) of the
> > > > TraxTransformer we get from time to time a NPE in one frame. Sometimes
> > > > its even worse: One frame contains part of the content of another frame
> > > > and the other frame is totally broken. Reloading the whole page brings
> > > > up all frames correctly.
> > > >
> > > > However if we turn off the storing we never did see this phenomenen. So
> > > > we assume that this problems have something to do with the storing.
> > > >
> > > > The store stores the Templates. Is it possible, that this problem can
> > > > occure, when several threads use the same Template (as delivered by the
> > > > store). A thread might finish first, resetting the template and the
> > > > other thread still try to use it.
> > >
> > > A Template IIRC should be thread safe but the actual transformation is
> > > done by a Transformer object which can be obtained from the Template (or
> > > is it the other way around?).
> > >
> > > Wait a second I'll try to do a stress test using ab....
> > >
> > > ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
> > >
> > > No, I can't reproduce the failure. All runs well here.
> > >
> > > Any guesses from the Xalan Team?
> > >
> > > Giacomo
> >
> > I ran accross this abnormality when I stress tested Cocoon using
> > Apache JRun. Please note, that I had to have the requests comming
> > _very_ quickly to to actually get it to show up.
>
> What is Apache JRun? The ab command I've use above uses 20 concurrent threads
> pounding a total of 200 requests on to a Tomcat 3.2.1 and the latest C2. Did
> you add more concurrent requests?
>
> Giacomo
Ooops, I meant Apache JMeter--I have been discussing alternative Application
Servers with people at my job, My brain farted on me.
I had 20 threads pounding every 300 ms +/- 300 ms with a gaussian dispersion
on the deviation. I actually got this running JMeter with 12 concurrent
threads every 1000 ms +/- 1000 ms with gaussian dispersion on deviation.
Note, that it was only once or twice. I didn't think too much of it because
the webapp we are designing won't be seeing that much activity. Note the
12 thread scenario corresponds to 1,036,800 page requests a day spread
evenly throughout the day.
I ran the test for ~20-30 seconds. It happened early in the test, but it
didn't happen again after that.
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Giacomo Pati <gi...@apache.org>.
Berin Loritsch wrote:
> Giacomo Pati wrote:
> > Carsten Ziegeler wrote:
> > > Hello,
> > >
> > > since the switch from the Xalan2D07 to the Xalan-2.0.0 version in
> > > Cocoon2 we get sometimes very strange problems.
> > >
> > > We are using frames which all four use the same stylesheets. The xalan
> > > is driven by the cocoon pipeline.
> > >
> > > If we turn on the storing (formerly known as caching) of the
> > > TraxTransformer we get from time to time a NPE in one frame. Sometimes
> > > its even worse: One frame contains part of the content of another frame
> > > and the other frame is totally broken. Reloading the whole page brings
> > > up all frames correctly.
> > >
> > > However if we turn off the storing we never did see this phenomenen. So
> > > we assume that this problems have something to do with the storing.
> > >
> > > The store stores the Templates. Is it possible, that this problem can
> > > occure, when several threads use the same Template (as delivered by the
> > > store). A thread might finish first, resetting the template and the
> > > other thread still try to use it.
> >
> > A Template IIRC should be thread safe but the actual transformation is
> > done by a Transformer object which can be obtained from the Template (or
> > is it the other way around?).
> >
> > Wait a second I'll try to do a stress test using ab....
> >
> > ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
> >
> > No, I can't reproduce the failure. All runs well here.
> >
> > Any guesses from the Xalan Team?
> >
> > Giacomo
>
> I ran accross this abnormality when I stress tested Cocoon using
> Apache JRun. Please note, that I had to have the requests comming
> _very_ quickly to to actually get it to show up.
What is Apache JRun? The ab command I've use above uses 20 concurrent threads
pounding a total of 200 requests on to a Tomcat 3.2.1 and the latest C2. Did
you add more concurrent requests?
Giacomo
>
> > > This is only a guess - has someone else had these problems?
> > >
> > > As they only occur occasionally it his very hard to reproduce them...
> > >
> > > Perhaps someone of you has a guess whats going on.
> > >
> > > The exception we get is the following:
> > >
> > > java.lang.NullPointerException
> > > at
> > > org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145) at
> > > org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
> > > Each.java:495)
> > > at
> > > org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
> > > tes.java:193)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > > ansformerImpl.java:2154)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > > ansformerImpl.java:2097)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
> > > sformerImpl.java:2029)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
> > > rImpl.java:1189)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
> > >
> > > :2894)
> > >
> > > This indicates that the ResultTreeHandler is not available (set to
> > > null).
> > >
> > > As most times everything is working fine it must have to do with the
> > > parallel usage of the stylesheets.
> > >
> > >
> > >
> > > Carsten Ziegeler
> > >
> > > Open Source Group sunShine - Lighting up e:Business
> > > ================================================================
> > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > www.sundn.de mailto:cziegeler@sundn.de
> > > ================================================================
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
>
> Carsten Ziegeler wrote:
> > Hello,
> >
> > since the switch from the Xalan2D07 to the Xalan-2.0.0 version in Cocoon2
> > we get sometimes very strange problems.
> >
> > We are using frames which all four use the same stylesheets. The xalan is
> > driven by the cocoon pipeline.
> >
> > If we turn on the storing (formerly known as caching) of the
> > TraxTransformer we get from time to time a NPE in one frame. Sometimes its
> > even worse: One frame contains part of the content of another frame and the
> > other frame is totally broken. Reloading the whole page brings up all
> > frames correctly.
> >
> > However if we turn off the storing we never did see this phenomenen. So we
> > assume that this problems have something to do with the storing.
> >
> > The store stores the Templates. Is it possible, that this problem can
> > occure, when several threads use the same Template (as delivered by the
> > store). A thread might finish first, resetting the template and the other
> > thread still try to use it.
>
> A Template IIRC should be thread safe but the actual transformation is done
> by a Transformer object which can be obtained from the Template (or is it the
> other way around?).
>
> Wait a second I'll try to do a stress test using ab....
>
> ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
>
> No, I can't reproduce the failure. All runs well here.
>
> Any guesses from the Xalan Team?
>
> Giacomo
I ran accross this abnormality when I stress tested Cocoon using
Apache JRun. Please note, that I had to have the requests comming
_very_ quickly to to actually get it to show up.
>
> >
> > This is only a guess - has someone else had these problems?
> >
> > As they only occur occasionally it his very hard to reproduce them...
> >
> > Perhaps someone of you has a guess whats going on.
> >
> > The exception we get is the following:
> >
> > java.lang.NullPointerException
> > at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145)
> > at
> > org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
> > Each.java:495)
> > at
> > org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
> > tes.java:193)
> > at
> > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > ansformerImpl.java:2154)
> > at
> > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > ansformerImpl.java:2097)
> > at
> > org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
> > sformerImpl.java:2029)
> > at
> > org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
> > rImpl.java:1189)
> > at
> > org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
> >
> > :2894)
> >
> > This indicates that the ResultTreeHandler is not available (set to null).
> >
> > As most times everything is working fine it must have to do with the
> > parallel usage of the stylesheets.
> >
> >
> >
> > Carsten Ziegeler
> >
> > Open Source Group sunShine - Lighting up e:Business
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto:cziegeler@sundn.de
> > ================================================================
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Giacomo Pati <gi...@apache.org>.
Davanum Srinivas wrote:
> Giacomo,
>
> > Wait a second I'll try to do a stress test using ab....
> > ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
>
> Where can i download this utility from?
It is normally included in your Apache httpd dist (or get it from cvs)
Giacomo
>
> Thanks,
> dims
>
> --- Giacomo Pati <gi...@apache.org> wrote:
> > Carsten Ziegeler wrote:
> > > Hello,
> > >
> > > since the switch from the Xalan2D07 to the Xalan-2.0.0 version in
> > > Cocoon2 we get sometimes very strange problems.
> > >
> > > We are using frames which all four use the same stylesheets. The xalan
> > > is driven by the cocoon pipeline.
> > >
> > > If we turn on the storing (formerly known as caching) of the
> > > TraxTransformer we get from time to time a NPE in one frame. Sometimes
> > > its even worse: One frame contains part of the content of another frame
> > > and the other frame is totally broken. Reloading the whole page brings
> > > up all frames correctly.
> > >
> > > However if we turn off the storing we never did see this phenomenen. So
> > > we assume that this problems have something to do with the storing.
> > >
> > > The store stores the Templates. Is it possible, that this problem can
> > > occure, when several threads use the same Template (as delivered by the
> > > store). A thread might finish first, resetting the template and the
> > > other thread still try to use it.
> >
> > A Template IIRC should be thread safe but the actual transformation is
> > done by a Transformer object which can be obtained from the Template (or
> > is it the other way around?).
> >
> > Wait a second I'll try to do a stress test using ab....
> >
> > ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
> >
> > No, I can't reproduce the failure. All runs well here.
> >
> > Any guesses from the Xalan Team?
> >
> > Giacomo
> >
> > > This is only a guess - has someone else had these problems?
> > >
> > > As they only occur occasionally it his very hard to reproduce them...
> > >
> > > Perhaps someone of you has a guess whats going on.
> > >
> > > The exception we get is the following:
> > >
> > > java.lang.NullPointerException
> > > at
> > > org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145) at
> > > org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
> > > Each.java:495)
> > > at
> > > org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
> > > tes.java:193)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > > ansformerImpl.java:2154)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > > ansformerImpl.java:2097)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
> > > sformerImpl.java:2029)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
> > > rImpl.java:1189)
> > > at
> > > org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
> > >
> > > :2894)
> > >
> > > This indicates that the ResultTreeHandler is not available (set to
> > > null).
> > >
> > > As most times everything is working fine it must have to do with the
> > > parallel usage of the stylesheets.
> > >
> > >
> > >
> > > Carsten Ziegeler
> > >
> > > Open Source Group sunShine - Lighting up e:Business
> > > ================================================================
> > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > www.sundn.de mailto:cziegeler@sundn.de
> > > ================================================================
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> =====
> Davanum Srinivas, JNI-FAQ Manager
> http://www.jGuru.com/faq/JNI
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35
> a year! http://personal.mail.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Davanum Srinivas <di...@yahoo.com>.
Giacomo,
> Wait a second I'll try to do a stress test using ab....
> ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
Where can i download this utility from?
Thanks,
dims
--- Giacomo Pati <gi...@apache.org> wrote:
> Carsten Ziegeler wrote:
> > Hello,
> >
> > since the switch from the Xalan2D07 to the Xalan-2.0.0 version in Cocoon2
> > we get sometimes very strange problems.
> >
> > We are using frames which all four use the same stylesheets. The xalan is
> > driven by the cocoon pipeline.
> >
> > If we turn on the storing (formerly known as caching) of the
> > TraxTransformer we get from time to time a NPE in one frame. Sometimes its
> > even worse: One frame contains part of the content of another frame and the
> > other frame is totally broken. Reloading the whole page brings up all
> > frames correctly.
> >
> > However if we turn off the storing we never did see this phenomenen. So we
> > assume that this problems have something to do with the storing.
> >
> > The store stores the Templates. Is it possible, that this problem can
> > occure, when several threads use the same Template (as delivered by the
> > store). A thread might finish first, resetting the template and the other
> > thread still try to use it.
>
> A Template IIRC should be thread safe but the actual transformation is done
> by a Transformer object which can be obtained from the Template (or is it the
> other way around?).
>
> Wait a second I'll try to do a stress test using ab....
>
> ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
>
> No, I can't reproduce the failure. All runs well here.
>
> Any guesses from the Xalan Team?
>
> Giacomo
>
> >
> > This is only a guess - has someone else had these problems?
> >
> > As they only occur occasionally it his very hard to reproduce them...
> >
> > Perhaps someone of you has a guess whats going on.
> >
> > The exception we get is the following:
> >
> > java.lang.NullPointerException
> > at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145)
> > at
> > org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
> > Each.java:495)
> > at
> > org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
> > tes.java:193)
> > at
> > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > ansformerImpl.java:2154)
> > at
> > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> > ansformerImpl.java:2097)
> > at
> > org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
> > sformerImpl.java:2029)
> > at
> > org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
> > rImpl.java:1189)
> > at
> > org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
> >
> > :2894)
> >
> > This indicates that the ResultTreeHandler is not available (set to null).
> >
> > As most times everything is working fine it must have to do with the
> > parallel usage of the stylesheets.
> >
> >
> >
> > Carsten Ziegeler
> >
> > Open Source Group sunShine - Lighting up e:Business
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto:cziegeler@sundn.de
> > ================================================================
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Giacomo Pati <gi...@apache.org>.
Carsten Ziegeler wrote:
> Hello,
>
> since the switch from the Xalan2D07 to the Xalan-2.0.0 version in Cocoon2
> we get sometimes very strange problems.
>
> We are using frames which all four use the same stylesheets. The xalan is
> driven by the cocoon pipeline.
>
> If we turn on the storing (formerly known as caching) of the
> TraxTransformer we get from time to time a NPE in one frame. Sometimes its
> even worse: One frame contains part of the content of another frame and the
> other frame is totally broken. Reloading the whole page brings up all
> frames correctly.
>
> However if we turn off the storing we never did see this phenomenen. So we
> assume that this problems have something to do with the storing.
>
> The store stores the Templates. Is it possible, that this problem can
> occure, when several threads use the same Template (as delivered by the
> store). A thread might finish first, resetting the template and the other
> thread still try to use it.
A Template IIRC should be thread safe but the actual transformation is done
by a Transformer object which can be obtained from the Template (or is it the
other way around?).
Wait a second I'll try to do a stress test using ab....
ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
No, I can't reproduce the failure. All runs well here.
Any guesses from the Xalan Team?
Giacomo
>
> This is only a guess - has someone else had these problems?
>
> As they only occur occasionally it his very hard to reproduce them...
>
> Perhaps someone of you has a guess whats going on.
>
> The exception we get is the following:
>
> java.lang.NullPointerException
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145)
> at
> org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
> Each.java:495)
> at
> org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
> tes.java:193)
> at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> ansformerImpl.java:2154)
> at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> ansformerImpl.java:2097)
> at
> org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
> sformerImpl.java:2029)
> at
> org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
> rImpl.java:1189)
> at
> org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
>
> :2894)
>
> This indicates that the ResultTreeHandler is not available (set to null).
>
> As most times everything is working fine it must have to do with the
> parallel usage of the stylesheets.
>
>
>
> Carsten Ziegeler
>
> Open Source Group sunShine - Lighting up e:Business
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto:cziegeler@sundn.de
> ================================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Strange problems with concurrent access of Xalan-2.0.0
Posted by Giacomo Pati <gi...@apache.org>.
Carsten Ziegeler wrote:
> Hello,
>
> since the switch from the Xalan2D07 to the Xalan-2.0.0 version in Cocoon2
> we get sometimes very strange problems.
>
> We are using frames which all four use the same stylesheets. The xalan is
> driven by the cocoon pipeline.
>
> If we turn on the storing (formerly known as caching) of the
> TraxTransformer we get from time to time a NPE in one frame. Sometimes its
> even worse: One frame contains part of the content of another frame and the
> other frame is totally broken. Reloading the whole page brings up all
> frames correctly.
>
> However if we turn off the storing we never did see this phenomenen. So we
> assume that this problems have something to do with the storing.
>
> The store stores the Templates. Is it possible, that this problem can
> occure, when several threads use the same Template (as delivered by the
> store). A thread might finish first, resetting the template and the other
> thread still try to use it.
A Template IIRC should be thread safe but the actual transformation is done
by a Transformer object which can be obtained from the Template (or is it the
other way around?).
Wait a second I'll try to do a stress test using ab....
ab -c 20 -n 200 http://localhost:8080/cocoon/welcome
No, I can't reproduce the failure. All runs well here.
Any guesses from the Xalan Team?
Giacomo
>
> This is only a guess - has someone else had these problems?
>
> As they only occur occasionally it his very hard to reproduce them...
>
> Perhaps someone of you has a guess whats going on.
>
> The exception we get is the following:
>
> java.lang.NullPointerException
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:145)
> at
> org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemFor
> Each.java:495)
> at
> org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTempla
> tes.java:193)
> at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> ansformerImpl.java:2154)
> at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Tr
> ansformerImpl.java:2097)
> at
> org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Tran
> sformerImpl.java:2029)
> at
> org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme
> rImpl.java:1189)
> at
> org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java
>
> :2894)
>
> This indicates that the ResultTreeHandler is not available (set to null).
>
> As most times everything is working fine it must have to do with the
> parallel usage of the stylesheets.
>
>
>
> Carsten Ziegeler
>
> Open Source Group sunShine - Lighting up e:Business
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto:cziegeler@sundn.de
> ================================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org