Project

Profile

Help

Bug #4788

Exception thrown in ExtensionFunctionCall prevents thread pool shutdown

Added by Eryk Rzeźnik 12 months ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Multithreading
Sprint/Milestone:
-
Start date:
2020-10-08
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
10, trunk
Fix Committed on Branch:
10, 9.9, trunk
Fixed in Maintenance Release:

Description

When exception is thrown in ExtensionFunctionCall.call method used inside for-each with multi-threaded processing enabled (saxon:threads attribute) then uderlying thread pool is not shutdow.

After running example (files: SaxonThreads.java, test.xslt, input.xml) you should be able to reproduce this problem. On attached screenshot (threads_count.jpg) from jconsole you can see number of threads in example program, after first few iterations exception is being thrown, and from this moment number of threads only increases.

Tested on version 9.7.0.21 and 9.9.1.7 with EE-T license.

threads_count.jpg (33.3 KB) threads_count.jpg Eryk Rzeźnik, 2020-10-08 11:42
SaxonThreads.java (3.09 KB) SaxonThreads.java Eryk Rzeźnik, 2020-10-08 11:42
input.xml (631 Bytes) input.xml Eryk Rzeźnik, 2020-10-08 11:42
test.xslt (482 Bytes) test.xslt Eryk Rzeźnik, 2020-10-08 11:42

History

#1 Updated by Michael Kay 11 months ago

  • Category set to Multithreading
  • Assignee set to Michael Kay

Thanks for reporting this. I have reproduced the problem, and I think it can be fixed quite easily.

I don't think the problem is particular to exceptions thrown by extension functions, it can probably be triggered by any dynamic error occurring within the multithreaded xsl:for-each.

#2 Updated by Michael Kay 11 months ago

Added an xslt3extra test case threads-029 which does a divide-by-zero within the loop.

This is failing slightly differently, with a RejectedExecutionException within MultithreadedContextMappingIterator.mapOneItem(). I'm not entirely sure what causes the two tests to fail in slightly different ways, but the remedy appears to be the same: when the exception is caught, call close() to shut down the ExecutorService

#3 Updated by Michael Kay 11 months ago

The difference between the two cases is that in one case, the call on expression.iterate() fails, while in the other the call on expression.iterate() returns an iterator and the call on iterator.next() fails. We should try and construct test cases for both situations...

#4 Updated by Michael Kay 11 months ago

  • Status changed from New to Resolved
  • Fix Committed on Branch 10, 9.9, trunk added

Added xslt30extra test cases threads-029, -030, and -031. Fix committed on 9.9, 10.x, and 11.x branches

#5 Updated by O'Neil Delpratt 11 months ago

  • Fixed in Maintenance Release 9.9.1.8 added

Bug fix applied on the Saxon 9.9.1.8 maintenance release. Leaving open until applied on the Saxon 10 maintenance release.

#6 Updated by O'Neil Delpratt 11 months ago

Bug fix applied in the Saxon 10.3 maintenance release

#7 Updated by O'Neil Delpratt 11 months ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.3 added

#8 Updated by Eryk Rzeźnik 5 months ago

I've tested attached example with versions 9.9.1.8 and 10.3, bugfix seems to work in 9.9.1.8, but in version 10.3 thread pool still is not closed after exception.

Can you confirm that this bugfix was actually applied on 10.3 version.

#9 Updated by Michael Kay 5 months ago

  • Status changed from Closed to In Progress

I've checked the commit logs and it seems there were three changes made on the 9.9 branch and only two of them were applied to the 10.x branch.

#10 Updated by Michael Kay 5 months ago

  • Status changed from In Progress to Resolved
  • Applies to branch 10, trunk added
  • Applies to branch deleted (9.7, 9.9)

I've now generated an automated unit test for this, and the patch is applied and tested on the 10.x and 11.x branches.

#11 Updated by O'Neil Delpratt 5 months ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 10.5 added
  • Fixed in Maintenance Release deleted (9.9.1.8, 10.3)

Bug fix applied to Saxon 10.5 maintenance release.

Please register to edit this issue

Also available in: Atom PDF