[XALANJ-2321] Multi-threading problem with AVTs

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 2.7.1
• Component/s: Xalan
• Environment: multi-processor systems
• Xalan info: PatchAvailable
• Assignee: Unassigned
• Reporter: Erin Harris
• Reviewer: Yash Talwar
• Created: 12/Sep/06 13:43
• Updated: 11/Dec/07 16:57
• Resolved: 30/Oct/06 18:37

Description

The following code in AVT.java is causing problems for multi-threaded test cases:

private final FastStringBuffer getBuffer(){
if(USE_OBJECT_POOL)

{ return StringBufferPool.get(); }

else if(m_cachedBuf == null)

{ m_cachedBuf = new FastStringBuffer(INIT_BUFFER_CHUNK_BITS); return m_cachedBuf; }

else if(m_cachedBuf.length() != 0)

{ return new FastStringBuffer(INIT_BUFFER_CHUNK_BITS); }else{ return m_cachedBuf; }
}

Because the same object node for the AVT is used by each thread, sometimes on one thread the buffer would be empty just as another thread is writing to it and thus both threads would write to the same buffer. This caused problems for a customer that used <xsl:element name="{local-name()}"> a lot and were running on a multi-processor machine.

The suggested fix is to change the code to the following, and remove the m_cachedBuf field:

private final FastStringBuffer getBuffer(){
if(USE_OBJECT_POOL){ return StringBufferPool.get(); }else{ return new FastStringBuffer(INIT_BUFFER_CHUNK_BITS); }

}

Issue Links

• is duplicated by: XALANJ-2322 CLONE -Data corrupted in Parallel XSL execution (when calling Extension Function) (https://issues.apache.org/jira/browse/XALANJ-2083)
• is duplicated by: XALANJ-2371 Possible Templates/Transformers threading issue