Hi, there were some problems with multi-threading and the environment stack which should be fixed by last monday - at least that's what I thought.
However, there is one subtle thing to keep in mind: ThreadLocal and InheritableThreadLocal variables! The current environment stack uses a InheritableThreadLocal variable - so you have to make sure that if you create/use a different thread that this InheritableThreadLocal variable is initialized correctly. Especially when you use thread-pools you have to manually set this variable (contained in the CocoonComponentManager) whenever you take a thread out of the pool and use it. Is it possible, that your problems are related to this? HTH Carsten Carsten Ziegeler Open Source Group, S&N AG -----Original Message----- From: Greg Weinger [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 4:23 AM To: cocoon-dev Subject: [SHOWSTOPPER?] cocoon sources no longer thread-safe 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(CoyoteRequestFa cade.java:325) at org.apache.cocoon.environment.http.HttpRequest.getQueryString(HttpRequest.ja va:178) at org.apache.cocoon.environment.wrapper.RequestWrapper.<init>(RequestWrapper.j ava:110) at org.apache.cocoon.environment.wrapper.EnvironmentWrapper.<init>(EnvironmentW rapper.java:149) at org.apache.cocoon.components.source.SitemapSource.<init>(SitemapSource.java: 204) at org.apache.cocoon.components.source.CocoonSourceFactory.getSource(CocoonSour ceFactory.java:91) at org.apache.cocoon.components.source.SourceHandlerImpl.getSource(SourceHandle rImpl.java:176) at org.apache.cocoon.environment.AbstractEnvironment.resolve(AbstractEnvironmen t.java:368) at dataserver.asynchronous.AsynchronousProcessorImpl.executeSource(Asynchronous ProcessorImpl.java:414) at dataserver.asynchronous.AsynchronousProcessorImpl$1.run(AsynchronousProcesso rImpl.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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
