Bug #2549
closedXQuery using saxon:stream leaves open thread in 9.7
100%
Description
In 9.7, iterating an XQuery result leaves an open thread, when the query accesses input via saxon:stream and does not process it completely.
Attaching a test program that demonstrates this behaviour.
Files
Updated by Michael Kay almost 9 years ago
- Category set to Streaming
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Fix Committed on Branch 9.7 added
Thanks for the clear test case.
When the iterator is closed, the idea is that the whole chain of underlying iterators should be closed, and eventually the iterator that reads from the provider thread signals the provider thread to close. But within the chain of underlying iterators is a ContextMappingIterator, which supports a construct such as A!B where there are two nested iterators, one for A and one for B. The iterator for A is being closed, but that for B is not, and it is the iterator for B that is connected to the provider thread.
Fixed by a patch to ContextMappingIterator.close().
Note: MappingIterator gets this right, it's only ContextMappingIterator that gets it wrong.
Updated by Michael Kay almost 9 years ago
- Applies to branch 9.6 added
- Fix Committed on Branch 9.6 added
The same problem is present in 9.6 and I have applied the patch there also.
Updated by O'Neil Delpratt almost 9 years ago
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.7.0.2 added
Bug fix applied in the Saxon 9.7.0.2 maintenance release
Updated by Gunther Rademacher almost 9 years ago
- File ThreadCountTest2.java ThreadCountTest2.java added
- Status changed from Resolved to Won't fix
- Sprint/Milestone set to 9.7.0.2
Thank you for taking care of this.
Meanwhile I have retested with Saxon 9.7.0.2. Though it does not happen in each iteration any more, there is still a chance of some thread being left over. The number varies in repeated executions of the test.
I have modified my test (now ThreadCountTest2) to show the stack traces of the left-over threads, and they all look the same:
number of threads increased from 6 to 8
Thread-1791
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:353)
com.saxonica.ee.stream.PushToPull$QueueWriter.write(PushToPull.java:63)
com.saxonica.ee.stream.PushToPull$Provider.run(PushToPull.java:95)
java.lang.Thread.run(Thread.java:745)
Thread-1793
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:353)
com.saxonica.ee.stream.PushToPull$QueueWriter.write(PushToPull.java:63)
com.saxonica.ee.stream.PushToPull$Provider.run(PushToPull.java:95)
java.lang.Thread.run(Thread.java:745)
Updated by Gunther Rademacher almost 9 years ago
Some further testing showed that the rate still is 1 thread left over per iteration of the test, when waiting some time before issuing close calls:
xdmSequenceIterator.next();
Thread.sleep(100);
xdmSequenceIterator.close();
xqueryEvaluator.close();
Please register to edit this issue