You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by "Brian Minchau (JIRA)" <xa...@xml.apache.org> on 2005/04/06 07:04:20 UTC
[jira] Resolved: (XALANJ-2046) StringBufferPool + FastStringBuffer are not thread safe
[ http://issues.apache.org/jira/browse/XALANJ-2046?page=history ]
Brian Minchau resolved XALANJ-2046:
-----------------------------------
Resolution: Invalid
Resolving as invalid, per the Xalan JIRA meeting April 5, 2005.
This issue is not deleted, just resolved as invalid.
The real issue is tracked at eclipse.org.
> 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
> 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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org