Hi, I fully agree with what was said before. but as a Solr newbie that gets lost quite a lot of times in jiras and PRs I want to say asking the list for guidance should be a good way to go about clarifying some peculiar implementation details.
Out of curiosity I dug up some links: - Jira https://issues.apache.org/jira/browse/SOLR-14749 - PR https://github.com/apache/solr/commit/67ecd8ff9ad3640016424ded86bfaaadd815b96d#diff-49651d6e4deb06bc01a835ba4acda45b5af54646cadc51a06bd2514a8112ad9cR99 I read through it and will add my 2 cents: it sure does smell like a bug to me, there is no way this works as intended in this order: add new item to map with same name and start it _then_ remove item from the map with same name and stop it. well unless the name of the old item and the new item are different but that does not look like the case here. hope this helps, alex On Tue, Aug 22, 2023 at 6:05 PM David Smiley <david.w.smi...@gmail.com> wrote: > Hi Paul, > > As a technique to inquire about "why" questions, I sometimes find the > original JIRA issue and/or PR and ask there. It may be a years-old > issue/PR but I personally think nothing of it -- it's practical as it pings > relevant people watching vs. a shot in the dark about an obscure matter. > > ~ David > > > On Tue, Aug 22, 2023 at 3:51 PM Paul McArthur > <pmcarthur-apa...@proton.me.invalid> wrote: > > > Hi all, > > > > I’m creating a cluster singleton plugin and have found an issue with the > > lifecycle management of the singleton if the plugin is updated via the > API. > > > > When the /cluster/plugin api is called with an update payload, the > > ClusterSingletons.modified method is called, which adds the new plugin to > > the singletonMap (and starts it if applicable). Then it stops and removes > > the old one. The order of these operations has a couple of side effects: > > > > 1. For a very brief period, there are 2 instances of the plugin running. > > This may not really be a problem, but does seem to violate the Singleton > > principle > > > > 2. Given that the map is keyed on the plugin name, adding the replacement > > first will overwrite the existing (old) entry in the map. Then when the > old > > one is removed, it actually removes the new one that was just added. This > > leaves the singletonMap with no entry for the plugin. When the Overseer > > node goes down, the stop method is not called for the plugin because it > no > > longer has an entry in the map. > > > > I’ve reproduced the issue by modifying the TestContainerPlugin test, and > I > > can create a Jira issue, but I wonder if there is any reason that the > added > > and deleted methods are called in this order that I haven’t understood. > It > > seems to me that reversing the order in which they are called will solve > > the issue. > > > > Thanks, > > Paul >
