Project

Profile

Help

Bug #2549

closed

XQuery using saxon:stream leaves open thread in 9.7

Added by Gunther Rademacher almost 9 years ago. Updated almost 9 years ago.

Status:
Won't fix
Priority:
Normal
Assignee:
Category:
Streaming
Sprint/Milestone:
Start date:
2015-12-17
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.6, 9.7
Fix Committed on Branch:
9.6, 9.7
Fixed in Maintenance Release:
Platforms:

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

ThreadCountTest.java (3.08 KB) ThreadCountTest.java Gunther Rademacher, 2015-12-17 15:53
ThreadCountTest2.java (3.44 KB) ThreadCountTest2.java Gunther Rademacher, 2016-01-20 11:21
Actions #1

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.

Actions #2

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.

Actions #3

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

Actions #4

Updated by Gunther Rademacher almost 9 years ago

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)
Actions #5

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

Also available in: Atom PDF