[ http://issues.apache.org/jira/browse/XALANJ-2046?page=all ]
Brian Minchau updated XALANJ-2046:
----------------------------------
Fix Version: 2.7
> StringBufferPool + FastStringBuffer are not thread safe
> -------------------------------------------------------
>
> Key: XALANJ-2046
> URL: http://issues.apache.org/jira/browse/XALANJ-2046
> Project: XalanJ2
> Type: Bug
> Versions: 2.6
> Environment: OS Name Microsoft(R) Windows(R) Server 2003, Enterprise Edition
> Version 5.2.3790 Build 3790
> OS Manufacturer Microsoft Corporation
> System Type X86-based PC
> 4 processors
> Processor x86 Family 15 Model 2 Stepping 9 GenuineIntel ~3056 Mhz
> Processor x86 Family 15 Model 2 Stepping 9 GenuineIntel ~3056 Mhz
> Processor x86 Family 15 Model 2 Stepping 9 GenuineIntel ~3056 Mhz
> Processor x86 Family 15 Model 2 Stepping 9 GenuineIntel ~3056 Mhz
> J2EE Server Websphere version 5.2
> Java version = J2RE 1.4.1 IBM Windows 32 build cn1411-20031011b (JIT enabled:
> jitc), Java Compiler = jitc, Java VM name = Classic VM
> Reporter: Carlo Marchiori
> Fix For: 2.7
> Attachments: src.zip
>
> org.apache.xml.utils.StringBufferPool + org.apache.xml.utils.FastStringBuffer
> are not thread safe.
> Under heavy load and after many invocation (I guess right after bytecode is
> compiled into machine code) I get the following exception:
> Caused by: java.lang.NegativeArraySizeException
> at java.lang.StringBuffer.<init>(StringBuffer.java(Compiled Code))
> at
> org.apache.xml.utils.FastStringBuffer.toString(FastStringBuffer.java:433)
> at org.apache.xalan.templates.AVT.<init>(AVT.java(Compiled Code))
> at
> org.apache.xalan.processor.XSLTAttributeDef.processAVT_QNAME(XSLTAttributeDef.java(Compiled
> Code))
> at
> org.apache.xalan.processor.XSLTAttributeDef.processValue(XSLTAttributeDef.java(Compiled
> Code))
> at
> org.apache.xalan.processor.XSLTAttributeDef.setAttrValue(XSLTAttributeDef.java(Compiled
> Code))
> at
> org.apache.xalan.processor.XSLTElementProcessor.setPropertiesFromAttributes(XSLTElementProcessor.java(Compiled
> Code))
> at
> org.apache.xalan.processor.XSLTElementProcessor.setPropertiesFromAttributes(XSLTElementProcessor.java(Inlined
> Compiled Code))
> at
> org.apache.xalan.processor.ProcessorTemplateElem.startElement(ProcessorTemplateElem.java(Compiled
> Code))
> at
> org.apache.xalan.processor.StylesheetHandler.startElement(StylesheetHandler.java(Compiled
> Code))
> at
> org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java(Compiled
> Code))
> at
> org.apache.xerces.impl.XMLNamespaceBinder.handleStartElement(XMLNamespaceBinder.java(Compiled
> Code))
> at
> org.apache.xerces.impl.XMLNamespaceBinder.startElement(XMLNamespaceBinder.java(Compiled
> Code))
> at
> org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java(Compiled
> Code))
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java(Compiled
> Code))
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java(Compiled
> Code))
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java(Compiled
> Code))
> at
> org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:524)
> at
> org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580)
> at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
> at
> org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1169)
> at
> org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:795)
> ... 37 more
> I managed to see that the instance fields of the FastStringBuffer instance
> are set to random values (negative in particular), and so the exception
> occurs.
> I think that the problem is due to incorrect coding.
> In fact the code is equivalent to the following
> ----------------------------------------------------------
> synchronized (...)
> {
> //acquire an fsb instance from static pool
> }
>
> //write to fsb instance fields
>
> synchronized (...)
> {
> //release the fsb instance into the static pool
> }
> ----------------------------------------------------------
>
> When the first synchronized block ends the local thread cache is flushed
> to main memory. When the second synchronized block begins the local thread
> cache
> is refreshed from main memory, but in this way all intervening writes may be
> lost.
> I propose the StringBufferPool to have the lifetime of a transformation and
> to belong to a single thread. I suggest further long running optimizations to
> be left to the underlying plaftorm.
> Carlo.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
