[JIRA] (MDA-275) Default stage configurations should not create daemon threads

[Ian Young (Jira)]

Ian Young ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ae127cb03-43ed-473d-b6ba-592949cb4be8 ) *created* an issue

Metadata Aggregator ( https://shibboleth.atlassian.net/browse/MDA?atlOrigin=eyJpIjoiNmY5YjY4NmMxZmFjNDJkMDkwNWEzNWY3OTFiOTc1MDEiLCJwIjoiaiJ9 ) / Improvement ( https://shibboleth.atlassian.net/browse/MDA-275?atlOrigin=eyJpIjoiNmY5YjY4NmMxZmFjNDJkMDkwNWEzNWY3OTFiOTc1MDEiLCJwIjoiaiJ9 ) MDA-275 ( https://shibboleth.atlassian.net/browse/MDA-275?atlOrigin=eyJpIjoiNmY5YjY4NmMxZmFjNDJkMDkwNWEzNWY3OTFiOTc1MDEiLCJwIjoiaiJ9 ) Default stage configurations should not create daemon threads ( https://shibboleth.atlassian.net/browse/MDA-275?atlOrigin=eyJpIjoiNmY5YjY4NmMxZmFjNDJkMDkwNWEzNWY3OTFiOTc1MDEiLCJwIjoiaiJ9 )

Issue Type: Improvement Affects Versions: 0.9.2 Assignee: Ian Young ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ae127cb03-43ed-473d-b6ba-592949cb4be8 ) Components: Pipeline Created: 01/Feb/23 6:16 AM Fix Versions: 0.10.0 Priority: Trivial Reporter: Ian Young ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ae127cb03-43ed-473d-b6ba-592949cb4be8 )

The PipelineDemultiplexerStage, PipelineMergeStage and SplitMergeStage create a default ExecutorService using Executors.newSingleThreadExecutor(). This in turn creates a default thread pool containing a single non-daemon thread.

The executorService field is not cleaned up in any way on bean destruction, and there’s no guarantee that garbage collection will ever solve this problem through finalisation (itself a deprecated feature), these non-daemon threads will survive the shutdown of the bean context. As well as being a leak of a somewhat limited resource, this can cause normal exit of the application to be infinitely deferred, as this normally waits until only daemon threads remain.

The temptation is to shut down the ExecutionService in the stage’s bean destroy code, but it’s not at all clear to me that is the right answer in principle (it would make sense for the creator of the resource to be responsible for its lifecycle) or in practice (if the stage has been configured with an explicit ExecutionService, it will no longer have a reference to the original one). We could invent (and document) some complicated rules for this, but it seems like an epicycle to me.

A more plausible option would be to create an executor which doesn’t create threads at all: after all, the idea by default is just to execute the jobs sequentially, then “wait” for their completion.

If the stages were defined in terms of Executor instead of ExecutorService, this would be a five-liner utility class (there’s an example of this code in the Executor Javadoc).

We should investigate whether we can make do with Executor and then convert if that’s the case. Note that ExecutorService is a subtype of Executor so this wouldn’t affect existing configurations. However, we’d need to provide our own equivalent of the submit method (returning a Future) to make this work; I suspect that’s fairly simple to do.

Alternatively, implementing a direct ExecutorService as opposed to a direct Executor is probably not that much more difficult; I am a little surprised I haven’t been able to locate one already.

( https://shibboleth.atlassian.net/browse/MDA-275#add-comment?atlOrigin=eyJpIjoiNmY5YjY4NmMxZmFjNDJkMDkwNWEzNWY3OTFiOTc1MDEiLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/MDA-275#add-comment?atlOrigin=eyJpIjoiNmY5YjY4NmMxZmFjNDJkMDkwNWEzNWY3OTFiOTc1MDEiLCJwIjoiaiJ9 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100214- sha1:06410ea )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20230201/5f7b64a4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-15a5a088-3d98-4056-b7c9-91ac72b5fc9f
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230201/5f7b64a4/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-a4131bed-897b-4b0b-a81f-d3c58ad6d4a9
Type: image/png
Size: 448 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230201/5f7b64a4/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-trivial-2d35a9fa-7758-4b7f-b3d1-67ebf8ff1542
Type: image/png
Size: 446 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230201/5f7b64a4/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-4a749936-31be-4518-a6d3-0600ef73e23f
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230201/5f7b64a4/attachment-0007.png>