SOLR-16391: Tweak v2 'CREATECORE' API to be more REST-ful
https://issues.apache.org/jira/browse/SOLR-16391
Description
V2(JAX-RS) Endpoints for core admin op "create" core.
Solution
Updated the core creation endpoint to use JAX-RS library. The plan is to use the existing v2 enpoints /api/cores, however, for now different one is using /api/cores/{coreName}/create, meanwhile working on resolving issue related to former path.
Tests
- Test valid create core command.
- Test creating core with existent configSet.
- Test creating core with non existent configSet.
- Test report error simultaneously firing two creating core commands.
Checklist
Please review the following and check all that apply:
- [x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
- [x] I have created a Jira issue and added the issue ID to my pull request title.
- [x] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
- [x] I have developed this patch against the
mainbranch. - [ ] I have run
./gradlew check. - [x] I have added tests for my changes.
- [ ] I have added documentation for the Reference Guide
NOt a comment per se on this PR, but more for my own education. In the CreateTool we use CoreAdminRequest.createCore. If we wanted to take advantage of this PR, would we replace CoreAdminRequest, or is it furthur into the createCore method? https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/cli/CreateTool.java#L186 ??
Not related to this change!
java.lang.AssertionError: expected same:org.apache.solr.request.SolrRequestInfo@922a9b2 was not:
at __randomizedtesting.SeedInfo.seed([BF8CAE2E1F3CCF8F]:0) at org.junit.Assert.fail(Assert.java:89) at org.junit.Assert.failNotSame(Assert.java:829) at org.junit.Assert.assertSame(Assert.java:772) at org.junit.Assert.assertSame(Assert.java:783) at org.apache.solr.request.TestSolrRequestInfo.lambda$testThreadPool$0(TestSolrRequestInfo.java:64) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:294) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
public void testThreadPool() throws InterruptedException {
final SolrRequestInfo info =
new SolrRequestInfo(
new LocalSolrQueryRequest(h.getCore(), params()), new SolrQueryResponse());
AtomicInteger counter = new AtomicInteger();
SolrRequestInfo.setRequestInfo(info);
ExecutorUtil.MDCAwareThreadPoolExecutor pool =
new ExecutorUtil.MDCAwareThreadPoolExecutor(
1, 1, 1, TimeUnit.SECONDS, new ArrayBlockingQueue<>(1));
AtomicBoolean run = new AtomicBoolean(false);
pool.execute(
() -> {
final SolrRequestInfo poolInfo = SolrRequestInfo.getRequestInfo();
assertSame(info, poolInfo);
info.addCloseHook(counter::incrementAndGet);
run.set(true);
});
if (random().nextBoolean()) {
pool.shutdown();
} else {
pool.shutdownNow();
}
SolrRequestInfo.clearRequestInfo();
SolrRequestInfo.reset();
pool.awaitTermination(1, TimeUnit.MINUTES);
assertTrue(run.get());
assertEquals("hook should be closed only once", 1, counter.get());
assertNull(SolrRequestInfo.getRequestInfo());
}
Above test failed during the build run, failed at
assertSame(info, poolInfo);
I believe before the Runnable got executed, other line SolrRequestInfo.clearRequestInfo(); which would pop SolrRequestInfo from the stack executed and When finally the Runnable started, it failed at assertSame(info, poolInfo).
The fix would be to move below code after the pool.awaitTermination() call but before the assert assertNull(SolrRequestInfo.getRequestInfo())
SolrRequestInfo.clearRequestInfo(); SolrRequestInfo.reset();
This PR had no visible activity in the past 60 days, labeling it as stale. Any new activity will remove the stale label. To attract more reviewers, please tag someone or notify the [email protected] mailing list. Thank you for your contribution!
This PR is now closed due to 60 days of inactivity after being marked as stale. Re-opening this PR is still possible, in which case it will be marked as active again.
Seems a shame to lose this one!