Re: [SHOWSTOPPER?] cocoon sources no longer thread-safe

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Hi!

I think that this can be the same origin of my problem with session
management.

We are getting mixed sessions from users. The curious is that before every
thing worked well. We have not changed nothing just some cosmetics (colors
and so on the application). In our test environment using JMeter Cocoon
got 100% stability.

This started since 25-Nov-2002 changes. But I dont remember from what date
was the old stable CVS 2.1.

I am currently "fighting" with the sessionManager to check where and when
this problem happens. I will keep you informed.

If you wish, tomorrow I can post the debug log.

Regards,

Antonio Gallardo.

Greg Weinger dijo:
> THE PROBLEM
> ----------------
> In 2.0.3 and before you could execute multiple cocoon:/  uris using the
> following code in a thread-safe manner:
>
>          Source  source = resolver.resolve(src);
>          source.toSAX(contentHandler);
>          source.recycle();
>
> We have an AsynchronousCIncludeTransformer that executes multiple
> pipelines this way.  Multiple threads from a pool use the same
> SourceResolver (from the initial request), to resolve and execute
> sources concurrently.
>
> This no longer works in the current 2.0.3branch.
>
>
>
> MORE DETAIL
> --------------------
> I believe that this has something to do with the Environment.  The
> recent fixes to the environment stack made things much better, but there
>  is still some subtle issue that hasn't been resolved (so to speak).
>
> Actually, it works correctly the first time I use our code, but Source
> resolving breaks on subsequent attempts.  It seems that some subtle
> aspect of the environment isn't being reset correctly.
>
> We get this error attempting to resolve the source:
> cocoon:/process?ds=demographics&id=1_1
>
> java.lang.NullPointerException
>     at
> org.apache.coyote.tomcat4.CoyoteRequestFacade.getQueryString(CoyoteRequestFacade.java:325)
>     at
> org.apache.cocoon.environment.http.HttpRequest.getQueryString(HttpRequest.java:178)
>     at
> org.apache.cocoon.environment.wrapper.RequestWrapper.<init>(RequestWrapper.java:110)
>     at
> org.apache.cocoon.environment.wrapper.EnvironmentWrapper.<init>(EnvironmentWrapper.java:149)
>     at
> org.apache.cocoon.components.source.SitemapSource.<init>(SitemapSource.java:204)
>     at
> org.apache.cocoon.components.source.CocoonSourceFactory.getSource(CocoonSourceFactory.java:91)
>     at
> org.apache.cocoon.components.source.SourceHandlerImpl.getSource(SourceHandlerImpl.java:176)
>     at
> org.apache.cocoon.environment.AbstractEnvironment.resolve(AbstractEnvironment.java:368)
>     at
> dataserver.asynchronous.AsynchronousProcessorImpl.executeSource(AsynchronousProcessorImpl.java:414)
>     at
> dataserver.asynchronous.AsynchronousProcessorImpl$1.run(AsynchronousProcessorImpl.java:345)
>     at dataserver.asynchronous.PooledThread.run(PooledThread.java:43
>
> I've tried catching the exception in the EnvironmentWrapper, to no avail
>  -- the Request that's passed along is no good.
>
>
>
> MY QUESTION
> -----------------------------
> 1) Is any of this ringing a bell?   Any clues?  Sylvain?
>
>
> I know this is difficult to test without a sample.  My hope is that the
> problem is significant enough to you committers to warrant fixing now.
>  I would be happy to put together a test case and example for you to
> debug on your own system.
>
> Also, I would love to donate the AsynchronousCIncludeTransformer.  It's
> slightly over-componentized at the moment, but I'll send it to anyone
> interested.
>
> Thanks,
> Greg




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org