[JIRA] (JSPT-118) Make Component Initialization & destruction non-idempotent

[Ian Young (Jira)]

Ian Young ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ae127cb03-43ed-473d-b6ba-592949cb4be8 ) *commented* on JSPT-118 ( https://shibboleth.atlassian.net/browse/JSPT-118?atlOrigin=eyJpIjoiMDNmNWMzMTNiYjMwNDhiMGEzNzc5MTNhMjU1MjVmMGIiLCJwIjoiaiJ9 )

Re: Make Component Initialization & destruction non-idempotent ( https://shibboleth.atlassian.net/browse/JSPT-118?atlOrigin=eyJpIjoiMDNmNWMzMTNiYjMwNDhiMGEzNzc5MTNhMjU1MjVmMGIiLCJwIjoiaiJ9 )

My previous comments about wanting to make sure things don’t get called more than once of course applies mainly to the doInitialise and doDestroy chains; I’m OK with the idea that initialize and destroy are idempotent.

The implementation in AbstractInitializableComponent, as you point out, attempts to assure this.

I’d also note, though, that the implementation in AbstractInitializableComponent also already uses synchronized to try to address the thread safety issue. So at a first glance, there’s nothing to do here.

The exception is your concern about deadlock, but I’m not sure that I understand the sequence of events you’re concerned with. Remember that a single thread can hold the lock on some objects and then re-enter their synchronized methods without deadlocking; it’s just other threads that can’t do that. So if a thread is in the middle of destroying component A which involves being in the middle of destroying component A, then calling back to component A’s destroy is just fine. While in that state, moreover, a second thread will be blocked from entering either object’s synchronized methods.

So there probably is a sequence of events which would result in deadlock but you need to lay it out in detail so that we can understand whether it’s an issue. I haven’t been able to find a plausible one, but maybe I just lack imagination.

( https://shibboleth.atlassian.net/browse/JSPT-118#add-comment?atlOrigin=eyJpIjoiMDNmNWMzMTNiYjMwNDhiMGEzNzc5MTNhMjU1MjVmMGIiLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/JSPT-118#add-comment?atlOrigin=eyJpIjoiMDNmNWMzMTNiYjMwNDhiMGEzNzc5MTNhMjU1MjVmMGIiLCJwIjoiaiJ9 )

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#100202- sha1:e905ae5 )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20220714/98633b29/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-0c2a557a-fe0a-4b98-8330-04035e53688c
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220714/98633b29/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-ccfb3807-e840-4af8-9f1f-b5fd37938be0
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220714/98633b29/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-5544524c-d9ee-4c67-b8db-94735b9282e7
Type: image/png
Size: 468 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220714/98633b29/attachment-0005.png>