gerlowskija commented on PR #1933: URL: https://github.com/apache/solr/pull/1933#issuecomment-1728321719
> I ran into a similar SolrCore ref-count issue on one other API. Let me try to remember what I did back then and hopefully I'll have a fix to discuss here shortly. This should be fixed now. Test it out and lmk if you're still able to reproduce. See [the fix](https://github.com/apache/solr/pull/1933/commits/030c5e0c795bb8e150bc7f40a08ba8138fd9f4c6) here. In short, when serving APIs, Solr attempts to distinguish whether an incoming request is trying to trigger core-specific or cluster-wide functionality. This has always been an easy question to answer for v1 APIs because of the relatively limited set of paths that those APIs use. But for some v2 APIs we occasionally have to "guess-and-check": we fetch the SolrCore (incrementing its ref-count), we try to find the API in the list that the SolrCore knows about, and then if that doesn't work we look elsewhere. In this case - where we fetched a SolrCore thinking the API might live there, only to be wrong- it turns out we weren't properly decrementing the ref-count for the SolrCore. > It turns out that if we put all of the JAX-RS annotations that describe the API on a Java interface that lives in a particular gradle module (instead of in the core module as we've done up to this point), then those annotations can be used to not just define the API, but also to drive client code generation! [...] There's a few [developer docs](https://github.com/apache/solr/blob/main/dev-docs/apis.adoc#writing-jax-rs-apis) that describe how to create the interface with all our JAX-RS annotations [...] If you don't mind, I can make the necessary tweaks to this PR to get it to work with our code generation? I went ahead and made these changes. With these changes, the build will now generate the following `SolrRequest` implementation "for free". Very cool IMO ``` public static class UnloadCoreResponse extends JacksonParsingResponse<SolrJerseyResponse> { public UnloadCoreResponse() { super(SolrJerseyResponse.class); } } public static class UnloadCore extends SolrRequest<UnloadCoreResponse> { private final UnloadCoreRequestBody requestBody; private final String coreName; /** * Create a UnloadCore request object. * * @param coreName Path param - */ public UnloadCore(String coreName) { super( SolrRequest.METHOD.valueOf("POST"), "/cores/{coreName}/unload".replace("{" + "coreName" + "}", coreName)); this.coreName = coreName; this.requestBody = new UnloadCoreRequestBody(); addHeader("Content-type", "application/json"); } /** * @param deleteIndex If true, will remove the index when unloading the core. */ public void setDeleteIndex(Boolean deleteIndex) { this.requestBody.deleteIndex = deleteIndex; } /** * @param deleteDataDir If true, removes the data directory and all sub-directories. */ public void setDeleteDataDir(Boolean deleteDataDir) { this.requestBody.deleteDataDir = deleteDataDir; } /** * @param deleteInstanceDir If true, removes everything related to the core, including the index * directory, configuration files and other related files. */ public void setDeleteInstanceDir(Boolean deleteInstanceDir) { this.requestBody.deleteInstanceDir = deleteInstanceDir; } /** * @param async Request ID to track this action which will be processed asynchronously. */ public void setAsync(String async) { this.requestBody.async = async; } // <snip> remainder of boilerplate definition removed } ``` ---- To summarize this all - I think the only outstanding issue at this point is whether to change the RequestBody class over to use `Boolean` instead of `boolean`. I can make that change if you don't object, or you're welcome to do it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
