Bug #2204
closed
Nested multithreaded xsl:for-each
Category:
Saxon extensions
Fix Committed on Branch:
9.6
Fixed in Maintenance Release:
Description
Saxon-EE allows an xsl:for-each instruction to operate in multithreaded mode by specifying the extension attribute saxon:threads="N".
This fails (typically causing the VM to hang) if several concurrent executions of the same multithreaded xsl:for-each instruction occur in parallel.
This might happen because the multithreaded xsl:for-each is nested (statically or dynamically) in another multithreaded xsl:for-each, or because the stylesheet containing the multithreaded xsl:for-each instruction is itself executed several times in parallel, for example by creating several XsltTransformer instances from the same XsltExecutable.
The problem has been re-created in a reproduceable test case, and a patch has been tested on the 9.6 branch.
- Status changed from New to Resolved
Now fixed on the 9.5, 9.6, and 9.7 branches.
The problem was that two variables (maxThreads and executionPool) evaluated during the course of evaluating the xsl:for-each instruction are held in instance-level variables of the MultithreadedForEach class, which is an expression class and therefore part of the compiled stylesheet, which is supposed to be threadsafe. It proved easy to change these to local variables held on stack.
The test case used was an adapted version of XSLT 3 test case catalog-005, adapted to put saxon:threads on two nested loops. No permanent test case has been created.
Bug fix applied in the Saxon 9.5.1.8 maintenance release
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in version set to 9.6.0.2
Bug fix applied to the maintenance release Saxon 9.6.0.2
- Sprint/Milestone set to 9.6.0.2
- Applies to branch 9.6 added
- Fix Committed on Branch 9.6 added
- Fixed in Maintenance Release 9.6.0.2 added
Please register to edit this issue
Also available in: Atom
PDF
.