Hi Michael, I think you're correct! A synchronization block is missing. It should be similar to the one in XSLTC.compile(). For some reason, TemplatesHandlerImpl is not using XSLTC.compile() and, as a result, it is not synchronizing the access to BCEL.
I will send you a patch for you to try ... Thanks for detailed explanation. -- Santiago ----- Original Message ----- From: "Michael Melhem" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, February 10, 2003 11:17 AM Subject: Re: Possible threading issue with xsltc and BCEL ?? > Hi Santiago, > > Thanks for looking into this. > > Within the context of Apache Cocoon, I can reproduce this error > everytime. This is done by opening the same web-app in two seperate > browser windows and clicking on a link in both browsers which uses > xsltc to compile a stylesheet. That is, we initiate > two seprate (simultaneous) requests to compile a stylesheet. > > As I said earler, it seems to me that the problem _may_ lie in the > apache.xalan.xsltc.trax.TemplatesHandlerImpl.java within the > getTemplates() method. > > What follows is a stack trace of the error we get. Note the original > exception occurs in a static method within the BCEL code. > > Is there a problem with how we are using xsltc, or is there are generic > threading issue with xsltc?? > > Please let me know what other information you might need. > > Many thanks, > Michael Melhem > > java.lang.ClassFormatError: Invalid method signature: > java/lang/String;)Ljava/lang/String; > at > org.apache.bcel.classfile.Utility.typeOfSignature(Utility.java:1019) > at org.apache.bcel.generic.Type.getType(Type.java:159) > at org.apache.bcel.generic.Type.getArgumentTypes(Type.java:221) > at > org.apache.bcel.generic.InvokeInstruction.consumeStack(InvokeInstruction.jav > a:99) > at org.apache.bcel.generic.MethodGen.getMaxStack(MethodGen.java:824) > at org.apache.bcel.generic.MethodGen.setMaxStack(MethodGen.java:717) > at > org.apache.xalan.xsltc.compiler.Mode.compileApplyTemplates(Mode.java:1047) > at > org.apache.xalan.xsltc.compiler.Stylesheet.compileModes(Stylesheet.java:447) > at > org.apache.xalan.xsltc.compiler.Stylesheet.translate(Stylesheet.java:548) > at > org.apache.xalan.xsltc.trax.TemplatesHandlerImpl.getTemplates(TemplatesHandl > erImpl.java:206) > at > org.apache.avalon.excalibur.xml.xslt.XSLTProcessorImpl.getTransformerHandler > AndValidity(XSLTProcessorImpl.java:224) > at > org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.java: > 333) > at > org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeli > ne(AbstractProcessingPipeline.java:390) > at > org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline > .setupPipeline(AbstractCachingProcessingPipeline.java:307) > at > org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(Abs > tractProcessingPipeline.java:484) > at > org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(Seri > alizeNode.java:149) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo > keNodes(AbstractParentProcessingNode.java:107) > at > org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectN > ode.java:146) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo > keNodes(AbstractParentProcessingNode.java:107) > at > org.apache.cocoon.components.treeprocessor.ContainerNode.invoke(ContainerNod > e.java:68) > at > org.apache.cocoon.components.treeprocessor.sitemap.CallNode.invoke(CallNode. > java:134) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo > keNodes(AbstractParentProcessingNode.java:83) > at > org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok > e(PreparableMatchNode.java:162) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo > keNodes(AbstractParentProcessingNode.java:107) > at > org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectN > ode.java:146) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo > keNodes(AbstractParentProcessingNode.java:83) > at > org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTyp > eNode.java:155) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo > keNodes(AbstractParentProcessingNode.java:107) > at > org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel > ineNode.java:153) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo > keNodes(AbstractParentProcessingNode.java:107) > at > org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe > linesNode.java:143)t > org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess > or.java:326) > at > org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess > or.java:308) > at > org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNod > e.java:131) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo > keNodes(AbstractParentProcessingNode.java:83) > at > org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok > e(PreparableMatchNode.java:162) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo > keNodes(AbstractParentProcessingNode.java:83) > at > org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTyp > eNode.java:155) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo > keNodes(AbstractParentProcessingNode.java:107) > at > org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel > ineNode.java:153) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo > keNodes(AbstractParentProcessingNode.java:107) > at > org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe > linesNode.java:143) > at > org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess > or.java:326) > at > org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess > or.java:308) > at org.apache.cocoon.Cocoon.process(Cocoon.java:643) > at > org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1046) > at javax.servlet.http.HttpServlet.service(HttpServlet.java) > at org.apache.tomcat.facade.ServletHandler.doService(Unknown Source) > at org.apache.tomcat.core.Handler.invoke(Unknown Source) > at org.apache.tomcat.core.Handler.service(Unknown Source) > at org.apache.tomcat.facade.ServletHandler.service(Unknown Source) > at org.apache.tomcat.core.ContextManager.internalService(Unknown > Source) > at org.apache.tomcat.core.ContextManager.service(Unknown Source) > at > org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Unknown > Source) > at org.apache.tomcat.util.net.TcpWorkerThread.runIt(Unknown Source) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:479) > > > On Mon, 10 Feb 2003, Santiago Pericas-Geertsen wrote: > > > Hi Michael, > > > This is the first time I hear about race conditions in relation to > > BCEL. However, I think that what you're describing is indeed > > plausible (yet, it seems, never caught by our multi-threaded tests). I'm > > going to start looking into this; if you have any additional info that > > could help us isolate the problem, we'd appreciate it. > > > > Thanks. > > > > -- Santiago > > > > On Mon, 10 Feb 2003, Michael Melhem wrote: > > >> Hi Xalan people, > >> > >> We (and some other Cocoon users) have come across a problem where if > >> effectively two threads happen to be compiling a stylesheet into > >> translet at the same time, threading issues seem to arise. > >> > >> Once the translet is intially compiled however, simultaneous access of the > >> translet is no longer a problem. > >> > >> AFAIK, the BCEL library is not thread safe by design, but there doesnt seem > >> to be any thread protection within the xsltc code that calls it. Is this case, > >> or am I missing something? Im not very familiar with the xsltc code, so > >> I was hoping that someone can enlighten me here ? > >> > >> These threading issues typically manifest themselves within static methods > >> of the bcel library. > >> > >> Re apache.xalan.xsltc.trax.TemplatesHandlerImpl.java: > >> > >> If I patch the code (that actually calls the bcel code) within the > >> getTemplates() method by adding a class-level synch block, this seems > >> to rectify the problem that we see. However, this seems like a very coarse > >> solution to me, and I dont what it means for performance issues if > >> anything. > >> > >> Many thanks, > >> Michael Melhem > >> > >> > >> > >> > >> > >
