Saxon

A client has reported that on occasions (once every few weeks) use of xsl:for-each with saxon:threads="N" will hang (that is, no threads make progress). The VM dump does not indicate any deadlock, so it appears to be some kind of livelock. We haven't succeeded in isolating a coding error that would account for the behaviour, but we have decided to retrofit an improved design for the feature from the 9.7 code base. The 9.6 implementation uses Saxon's Conduit class, which is a very basic implementation of a shared producer/consumer queue synchronized using Java primitives. The 9.7 implementation replaces this with a LinkedBlockingQueue from the Java concurrency framework.

We've also identified some potential for concurrency problems when a multi-threaded xsl:for-each loop does lazy evaluation of variables declared outside the loop: see http://dev.saxonica.com/blog/mike/2015/06/lazy-evaluation.html. To reduce the possibility of such problems, we decided to evaluate such variables eagerly. The same code also fixes a problem with try/catch, in that lazy evaluation of variables within a try/catch can cause dynamic errors to be caught that should not be.

We are therefore committing two patches to the 9.6 code-base: a rewrite of the multithreaded execution for xsl:for-each with a saxon:threads attribute, and a change to the execution plan for local variables so that eager evaluation is used if any reference to the variable appears within (a) a multi-threaded xsl:for-each, (b) a try/catch block, or (c) a multi-threaded xsl:result-document instruction (and where the declaration of the variable appears outside that construct).