[
https://issues.apache.org/jira/browse/SOLR-15085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Owen updated SOLR-15085:
----------------------------
Labels: pull-request-available (was: )
> EmbeddedSolrServer calls shutdown on a provided CoreContainer
> -------------------------------------------------------------
>
> Key: SOLR-15085
> URL: https://issues.apache.org/jira/browse/SOLR-15085
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server, SolrJ
> Affects Versions: master (9.0)
> Reporter: Tim Owen
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are essentially 2 ways to create an EmbeddedSolrServer object, one by
> passing in a CoreContainer object, and the other way creates one internally
> on-the-fly. The current behaviour of the close method calls shutdown on the
> CoreContainer, regardless of where it came from.
> I believe this is not good behaviour for a class that doesn't control the
> lifecycle of the passed-in CoreContainer. In fact, there are 4 cases among
> the codebase where a subclass of EmbeddedSolrServer is created just to
> override this behaviour (with a comment saying it's unwanted).
> In my use-case I create EmbeddedSolrServer instances for cores as and when I
> need to work with them, but the CoreContainer exists for the duration. I
> don't want the whole container shut down when I'm done with just one of its
> cores. You can workaround it by just not calling close on the
> EmbeddedSolrServer object, but that's risky especially if you use a
> try-with-resources as close is called automatically then.
> Fix is to keep track of whether the CoreContainer was created internally or
> not, and only shut it down if internal. I will attach my patch PR.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
