Bug #2635
closed
XQuery using saxon:stream leaves open thread, when closed prematurely
100%
Description
This is similar to Bug #2549. In fact I had already commented there, but apparently I managed to set its status to "Won't fix" (can't remember how I did that), which was meant as "the fix won't solve the problem", though. Anyway.
When reading a result from an XQuery using saxon:stream, then a thread is left over if
-
the result is closed prematurely,
-
but there is some delay between reading and closing.
The attached ThreadCountTest3 demonstrates this behaviour, piling up 100 threads in 100 iterations.
Files
Updated by Gunther Rademacher about 8 years ago
That was tested with both Saxon-EE 9.7.0.2J and Saxon-EE 9.7.0.3J. The fix for Bug #2549 had improved it in case there was no delay before the close, but with the delay a thread is left over on each iteration.
Updated by Michael Kay about 8 years ago
I think that what is happening is this: The consuming process successfully signals to the provider that no more input is required and it should shut down. The provider is successfully interrupted, and as part of its closedown process it throws a "parsing abandoned" exception, which it then tries to notify to the consumer, which of course isn't interested.
Updated by Michael Kay about 8 years ago
- Category set to Streaming
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Applies to branch 9.7 added
- Fix Committed on Branch 9.7 added
Fixed (on 9.7 branch) by ensuring that after receiving a QuitParsingException, the provider thread no longer attempts to write either a "finished" message or an exception message to the shared queue.
Updated by Michael Kay about 8 years ago
- Status changed from Resolved to In Progress
Re-opening. The patch causes regression in some XSLT streaming tests, notably tests where xsl:stream in XSLT does not need to read the whole stream. An example is sf-boolean-001. The effect is that the test fails throwing the QuitParsingException which should be caught and suppressed when thrown by the SAX parser.
Updated by Michael Kay about 8 years ago
So the basic issue is that when a StreamInstr (effectively xsl:stream) is executed in the main thread, as happens with these XSLT test cases, it needs to return indicating successful completion, even though the parse was abandoned; but in the two-thread case, as happens with the XQuery test case, it needs to return differently from a successful completion, because the calling code needs to know that no completion message should be sent from the provider to the consumer.
There doesn't seem to be any completely straightforward way of achieving this difference in behaviour.
Updated by Michael Kay about 8 years ago
- Status changed from In Progress to Resolved
I have resolved this with a revised patch as follows:
(a) The class PushToPull (which evaluates an expression in pull mode by starting a new thread to do the evaluation in push mode and write the results to a queue which is read by the original thread) can no longer handle any expression, it now specifically handles a StreamInstr.
(b) StreamInstr has a new method push() which performs the evaluation in push mode and throws QuitParsingException in the event of early exit.
(c) StreamInstr.processLeavingTail() calls push() and ignores the QuitParsingException
(d) PushToPull.run() calls StreamInstr.push() and catches the QuitParsingException, with the effect that when it occurs, no final completion message is written to the shared queue.
Updated by O'Neil Delpratt about 8 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.7.0.4 added
Bug fix applied in the Saxon 9.7.0.4 maintenance release.
Please register to edit this issue
.