[jira] [Created] (SOLR-16681) Replacement field via fl doesn't work since 9.1
Mikhail Khludnev created SOLR-16681:
---
Summary: Replacement field via fl doesn't work since 9.1
Key: SOLR-16681
URL: https://issues.apache.org/jira/browse/SOLR-16681
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Mikhail Khludnev
User reported a use case which were working before 9.1 but not anymore.
The point is to logically replace a field (hereby it's {{id}} but it might
behave same for any other)
{{fl=old_id:id,id:new_id}}
I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple reproducer.
see the link. Then I applied it to revision preceding and test passed. For me
it seems like:
- Solr behave like described before, but not after .
- Should we reproduce this behavior or we can suggest a workaround?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] mkhludnev opened a new pull request, #1384: SOLR-16681: Reproducer attempting to replace fields via fl
mkhludnev opened a new pull request, #1384: URL: https://github.com/apache/solr/pull/1384 https://issues.apache.org/jira/browse/SOLR-16681 https://lists.apache.org/thread/vrbsm8wy14t0xgfk0og3pkvj8s0123rd -- 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
[jira] [Updated] (SOLR-16681) Replacement field via fl doesn't work since 9.1
[
https://issues.apache.org/jira/browse/SOLR-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-16681:
Description:
User reported a use case which were working before 9.1 but not anymore.
The point is to logically replace a field (hereby it's {{id}} but it might
behave same for any other)
{{fl=old_id:id,id:new_id}}
I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
[reproducer|https://github.com/apache/solr/pull/1384]. see the link. Then I
applied it to revision preceding and test passed. For me it seems like:
- Solr behave like described before, but not after .
- Should we reproduce this behavior or we can suggest a workaround?
was:
User reported a use case which were working before 9.1 but not anymore.
The point is to logically replace a field (hereby it's {{id}} but it might
behave same for any other)
{{fl=old_id:id,id:new_id}}
I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple reproducer.
see the link. Then I applied it to revision preceding and test passed. For me
it seems like:
- Solr behave like described before, but not after .
- Should we reproduce this behavior or we can suggest a workaround?
> Replacement field via fl doesn't work since 9.1
> ---
>
> Key: SOLR-16681
> URL: https://issues.apache.org/jira/browse/SOLR-16681
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User reported a use case which were working before 9.1 but not anymore.
> The point is to logically replace a field (hereby it's {{id}} but it might
> behave same for any other)
> {{fl=old_id:id,id:new_id}}
> I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
> [reproducer|https://github.com/apache/solr/pull/1384]. see the link. Then I
> applied it to revision preceding and test passed. For me it seems like:
> - Solr behave like described before, but not after .
> - Should we reproduce this behavior or we can suggest a workaround?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16681) Replacement field via fl doesn't work since 9.1
[
https://issues.apache.org/jira/browse/SOLR-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-16681:
Description:
User reported a use case which were working before 9.1 but not anymore.
The point is to logically replace a field (hereby it's {{id}} but it might
behave same for any other)
{{fl=old_id:id,id:new_id}}
I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
[reproducer|https://github.com/apache/solr/pull/1384]. see the link. Then I
applied it to revision preceding
[SOLR-9376|https://github.com/mkhludnev/solr/commit/6ff81312607dd5d33f87dc52aed9d52938dc6883#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
and test passed. For me it seems like:
- Solr behave like described before, but not after SOLR-9376.
- Should we reproduce this behavior or we can suggest a workaround?
was:
User reported a use case which were working before 9.1 but not anymore.
The point is to logically replace a field (hereby it's {{id}} but it might
behave same for any other)
{{fl=old_id:id,id:new_id}}
I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
[reproducer|https://github.com/apache/solr/pull/1384]. see the link. Then I
applied it to revision preceding and test passed. For me it seems like:
- Solr behave like described before, but not after .
- Should we reproduce this behavior or we can suggest a workaround?
> Replacement field via fl doesn't work since 9.1
> ---
>
> Key: SOLR-16681
> URL: https://issues.apache.org/jira/browse/SOLR-16681
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User reported a use case which were working before 9.1 but not anymore.
> The point is to logically replace a field (hereby it's {{id}} but it might
> behave same for any other)
> {{fl=old_id:id,id:new_id}}
> I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
> [reproducer|https://github.com/apache/solr/pull/1384]. see the link. Then I
> applied it to revision preceding
> [SOLR-9376|https://github.com/mkhludnev/solr/commit/6ff81312607dd5d33f87dc52aed9d52938dc6883#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
> and test passed. For me it seems like:
> - Solr behave like described before, but not after SOLR-9376.
> - Should we reproduce this behavior or we can suggest a workaround?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16681) Replacement field via fl doesn't work since 9.1
[
https://issues.apache.org/jira/browse/SOLR-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17693464#comment-17693464
]
Mikhail Khludnev commented on SOLR-16681:
-
I've found some ResultTransformer renaming fields, can't we use it as
workaround?
> Replacement field via fl doesn't work since 9.1
> ---
>
> Key: SOLR-16681
> URL: https://issues.apache.org/jira/browse/SOLR-16681
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User reported a use case which were working before 9.1 but not anymore.
> The point is to logically replace a field (hereby it's {{id}} but it might
> behave same for any other)
> {{fl=old_id:id,id:new_id}}
> I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
> [reproducer|https://github.com/apache/solr/pull/1384]. see the link. Then I
> applied it to revision preceding
> [SOLR-9376|https://github.com/mkhludnev/solr/commit/6ff81312607dd5d33f87dc52aed9d52938dc6883#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
> and test passed. For me it seems like:
> - Solr behave like described before, but not after SOLR-9376.
> - Should we reproduce this behavior or we can suggest a workaround?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16681) Replacement field via fl doesn't work since 9.1
[
https://issues.apache.org/jira/browse/SOLR-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-16681:
Description:
User reported a use case which were working before 9.1 but not anymore.
The point is to logically replace a field (hereby it's {{id}} but it might
behave same for any other)
{{fl=old_id:id,id:new_id}}
I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
[reproducer|https://github.com/apache/solr/pull/1384]. see the link. [Then I
applied
it|https://github.com/mkhludnev/solr/tree/SOLR-16681-proves-work-before] to
revision preceding
[SOLR-9376|https://github.com/mkhludnev/solr/commit/6ff81312607dd5d33f87dc52aed9d52938dc6883#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
and test passed. For me it seems like:
- Solr behave like described before, but not after SOLR-9376.
- Should we reproduce this behavior or we can suggest a workaround?
was:
User reported a use case which were working before 9.1 but not anymore.
The point is to logically replace a field (hereby it's {{id}} but it might
behave same for any other)
{{fl=old_id:id,id:new_id}}
I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
[reproducer|https://github.com/apache/solr/pull/1384]. see the link. Then I
applied it to revision preceding
[SOLR-9376|https://github.com/mkhludnev/solr/commit/6ff81312607dd5d33f87dc52aed9d52938dc6883#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
and test passed. For me it seems like:
- Solr behave like described before, but not after SOLR-9376.
- Should we reproduce this behavior or we can suggest a workaround?
> Replacement field via fl doesn't work since 9.1
> ---
>
> Key: SOLR-16681
> URL: https://issues.apache.org/jira/browse/SOLR-16681
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User reported a use case which were working before 9.1 but not anymore.
> The point is to logically replace a field (hereby it's {{id}} but it might
> behave same for any other)
> {{fl=old_id:id,id:new_id}}
> I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
> [reproducer|https://github.com/apache/solr/pull/1384]. see the link. [Then I
> applied
> it|https://github.com/mkhludnev/solr/tree/SOLR-16681-proves-work-before] to
> revision preceding
> [SOLR-9376|https://github.com/mkhludnev/solr/commit/6ff81312607dd5d33f87dc52aed9d52938dc6883#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
> and test passed. For me it seems like:
> - Solr behave like described before, but not after SOLR-9376.
> - Should we reproduce this behavior or we can suggest a workaround?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16681) Replacement field via fl doesn't work since 9.1
[
https://issues.apache.org/jira/browse/SOLR-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-16681:
Description:
User reported a use case which were working before 9.1 but not anymore.
The point is to logically replace a field (hereby it's {{id}} but it might
behave same for any other)
{{fl=old_id:id,id:new_id}}
I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
[reproducer|https://github.com/apache/solr/pull/1384]. see the link. [Then I
applied
it|https://github.com/mkhludnev/solr/tree/SOLR-16681-proves-work-before] to
revision preceding
[SOLR-9376|https://github.com/mkhludnev/solr/commit/6ff81312607dd5d33f87dc52aed9d52938dc6883#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
and test passed. For me it seems like:
- Solr behave like described before, but does not after SOLR-9376.
- Should we reproduce this behavior or we can suggest a workaround?
was:
User reported a use case which were working before 9.1 but not anymore.
The point is to logically replace a field (hereby it's {{id}} but it might
behave same for any other)
{{fl=old_id:id,id:new_id}}
I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
[reproducer|https://github.com/apache/solr/pull/1384]. see the link. [Then I
applied
it|https://github.com/mkhludnev/solr/tree/SOLR-16681-proves-work-before] to
revision preceding
[SOLR-9376|https://github.com/mkhludnev/solr/commit/6ff81312607dd5d33f87dc52aed9d52938dc6883#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
and test passed. For me it seems like:
- Solr behave like described before, but not after SOLR-9376.
- Should we reproduce this behavior or we can suggest a workaround?
> Replacement field via fl doesn't work since 9.1
> ---
>
> Key: SOLR-16681
> URL: https://issues.apache.org/jira/browse/SOLR-16681
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User reported a use case which were working before 9.1 but not anymore.
> The point is to logically replace a field (hereby it's {{id}} but it might
> behave same for any other)
> {{fl=old_id:id,id:new_id}}
> I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
> [reproducer|https://github.com/apache/solr/pull/1384]. see the link. [Then I
> applied
> it|https://github.com/mkhludnev/solr/tree/SOLR-16681-proves-work-before] to
> revision preceding
> [SOLR-9376|https://github.com/mkhludnev/solr/commit/6ff81312607dd5d33f87dc52aed9d52938dc6883#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
> and test passed. For me it seems like:
> - Solr behave like described before, but does not after SOLR-9376.
> - Should we reproduce this behavior or we can suggest a workaround?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] mkhludnev opened a new pull request, #1385: mv via fl worked before
mkhludnev opened a new pull request, #1385: URL: https://github.com/apache/solr/pull/1385 https://issues.apache.org/jira/browse/SOLR-16681 -- 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
[jira] [Commented] (SOLR-16681) Replacement field via fl doesn't work since 9.1
[
https://issues.apache.org/jira/browse/SOLR-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17693492#comment-17693492
]
Mikhail Khludnev commented on SOLR-16681:
-
Wait a sec.. it might actually work
{code}
1010
{code}
???
> Replacement field via fl doesn't work since 9.1
> ---
>
> Key: SOLR-16681
> URL: https://issues.apache.org/jira/browse/SOLR-16681
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User reported a use case which were working before 9.1 but not anymore.
> The point is to logically replace a field (hereby it's {{id}} but it might
> behave same for any other)
> {{fl=old_id:id,id:new_id}}
> I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
> [reproducer|https://github.com/apache/solr/pull/1384]. see the link. [Then I
> applied
> it|https://github.com/mkhludnev/solr/tree/SOLR-16681-proves-work-before] to
> revision preceding
> [SOLR-9376|https://github.com/mkhludnev/solr/commit/6ff81312607dd5d33f87dc52aed9d52938dc6883#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
> and test passed. For me it seems like:
> - Solr behave like described before, but does not after SOLR-9376.
> - Should we reproduce this behavior or we can suggest a workaround?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] dsmiley commented on a diff in pull request #1374: SOLR-16623:SolrClientTestRule for JettySolrRunnerV2
dsmiley commented on code in PR #1374:
URL: https://github.com/apache/solr/pull/1374#discussion_r1117980789
##
solr/core/src/test/org/apache/solr/TestSolrCoreProperties.java:
##
@@ -93,7 +91,7 @@ public void testSimple() throws Exception {
params(
"q", "*:*",
"echoParams", "all");
-QueryResponse res = getSolrClient().query(params);
+QueryResponse res =
solrClientTestRule.getSolrClient(TestSolrCoreProperties.this).query(params);
assertEquals(0, res.getResults().getNumFound());
Review Comment:
Can't we keep this as it was? Don't want to update tests unnecessarily.
##
solr/core/src/test/org/apache/solr/request/TestStreamBody.java:
##
@@ -61,19 +62,16 @@ public void before() throws Exception {
if (random().nextBoolean()) {
log.info("These tests are run with V2 API");
restTestHarness.setServerProvider(
- () -> jetty.getBaseUrl().toString() + "/v2/cores/" +
DEFAULT_TEST_CORENAME);
+ () -> getJetty().getBaseUrl().toString() + "/v2/cores/" +
DEFAULT_TEST_CORENAME);
}
}
@After
public void after() throws Exception {
-if (jetty != null) {
- jetty.stop();
- jetty = null;
-}
-if (client != null) {
- client.close();
- client = null;
+solrClientTestRule.reset();
+if (SolrJettyTestRule.getClient() != null) {
+ SolrJettyTestRule.getClient().close();
+ SolrJettyTestRule.client = null;
Review Comment:
_Palm-to-face_! My suspicion is that you did a refactoring initiated by
your IDE and didn't check its results.
##
solr/test-framework/src/java/org/apache/solr/util/SolrJettyTestRule.java:
##
@@ -0,0 +1,130 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.util;
+
+import static org.apache.solr.SolrTestCaseJ4.DEFAULT_TEST_CORENAME;
+import static org.apache.solr.SolrTestCaseJ4.getHttpSolrClient;
+
+import java.io.IOException;
+import java.lang.invoke.MethodHandles;
+import java.nio.file.Path;
+import java.util.Properties;
+import java.util.concurrent.ConcurrentHashMap;
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.client.solrj.SolrClient;
+import org.apache.solr.embedded.JettyConfig;
+import org.apache.solr.embedded.JettySolrRunner;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+public class SolrJettyTestRule extends SolrClientTestRule {
+ private static final Logger log =
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
+ private SolrClient client = null;
+ private JettySolrRunner jetty;
+ private SolrClient adminClient = null;
+
+ private ConcurrentHashMap clients =
+ new ConcurrentHashMap<>(); // TODO close them
+
+ public SolrClient getClient() {
+return client;
+ }
+
+ @Override
+ protected void after() {
+if (adminClient != null) {
+ try {
+adminClient.close();
+ } catch (IOException e) {
+throw new RuntimeException(e);
+ }
+}
+adminClient = null;
+
+if (jetty != null) {
+
+ try {
+jetty.stop();
+ } catch (RuntimeException e) {
+throw e;
+ } catch (Exception e) {
+throw new RuntimeException(e);
+ }
+ jetty = null;
+}
+
+if (client != null) {
+ try {
+client.close();
+ } catch (IOException e) {
+throw new RuntimeException(e);
+ }
+ client = null;
+}
+ }
+
+ @Deprecated // Prefer not to have this.
+ public void reset() {
+after();
+ }
+
+ @Override
+ public void startSolr(Path solrHome) {
+startSolr(
+solrHome,
+new Properties(),
+JettyConfig.builder()
+.withSSLConfig(SolrTestCaseJ4.sslConfig.buildServerSSLConfig())
+.build());
+ }
+
+ public void startSolr(Path solrHome, Properties nodeProperties, JettyConfig
jettyConfig) {
+
Review Comment:
Let's check "jetty" isn't already set? Would be nasty if this were to
happen accidentally.
##
solr/test-framework/src/java/org/apache/solr/util/SolrJettyTestRule.java:
##
@@ -52,13 +53,18 @@ protected void after() {
try {
jetty.stop();
} catch (Exception e) {
-
[GitHub] [solr] dsmiley commented on a diff in pull request #1374: SOLR-16623:SolrClientTestRule for JettySolrRunnerV2
dsmiley commented on code in PR #1374:
URL: https://github.com/apache/solr/pull/1374#discussion_r1117988442
##
solr/test-framework/src/java/org/apache/solr/util/SolrClientTestRule.java:
##
@@ -135,14 +135,16 @@ protected void create(NewCollectionBuilder b) throws
SolrServerException, IOExce
req.process(getAdminClient());
}
- /** Provides a SolrClient instance for administration actions */
+ /**
+ * Provides a SolrClient instance for administration actions. The caller
doesn't need to close it
+ */
public abstract SolrClient getAdminClient();
- /** Provides a SolrClient instance for collection1 */
+ /** Provides a SolrClient instance for collection1. The caller doesn't need
to close it */
public SolrClient getSolrClient() {
return getSolrClient("collection1");
}
-
+ /** Provides a SolrClient instance for provided name. The caller doesn't
need to close it */
Review Comment:
"For provided name"? And what is this "name"?
##
solr/core/src/test/org/apache/solr/core/TestConfigSetImmutable.java:
##
@@ -65,11 +66,8 @@ public void before() throws Exception {
@After
public void after() throws Exception {
-if (jetty != null) {
- jetty.stop();
- jetty = null;
-}
-client = null;
+solrClientTestRule.reset();
+SolrJettyTestRule.client = null;
Review Comment:
Looking at the state of SolrJettyTestRule right now, it's already *not*
static and is public -- which is good. Your PR doesn't compile. I suggest
never pushing code that doesn't even compile.
##
solr/test-framework/src/java/org/apache/solr/util/SolrJettyTestRule.java:
##
@@ -0,0 +1,130 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.util;
+
+import static org.apache.solr.SolrTestCaseJ4.DEFAULT_TEST_CORENAME;
+import static org.apache.solr.SolrTestCaseJ4.getHttpSolrClient;
+
+import java.io.IOException;
+import java.lang.invoke.MethodHandles;
+import java.nio.file.Path;
+import java.util.Properties;
+import java.util.concurrent.ConcurrentHashMap;
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.client.solrj.SolrClient;
+import org.apache.solr.embedded.JettyConfig;
+import org.apache.solr.embedded.JettySolrRunner;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+public class SolrJettyTestRule extends SolrClientTestRule {
+ private static final Logger log =
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
+ private SolrClient client = null;
+ private JettySolrRunner jetty;
+ private SolrClient adminClient = null;
+
+ private ConcurrentHashMap clients =
+ new ConcurrentHashMap<>(); // TODO close them
Review Comment:
That's a critical TODO by the way, and an easy one to get done.
--
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
[GitHub] [solr] dsmiley commented on a diff in pull request #760: SOLR-16116: Use apache curator to manage the Solr Zookeeper interactions
dsmiley commented on code in PR #760:
URL: https://github.com/apache/solr/pull/760#discussion_r1117990007
##
solr/solrj/src/java/org/apache/solr/common/cloud/SolrZkClient.java:
##
@@ -147,125 +154,93 @@ public SolrZkClient(
String zkServerAddress,
int zkClientTimeout,
int clientConnectTimeout,
- ZkClientConnectionStrategy strat,
+ ZkCredentialsProvider zkCredentialsProvider,
final OnReconnect onReconnect,
- BeforeReconnect beforeReconnect) {
+ OnDisconnect onDisconnect) {
this(
zkServerAddress,
zkClientTimeout,
clientConnectTimeout,
-strat,
-onReconnect,
-beforeReconnect,
+zkCredentialsProvider,
null,
+onReconnect,
+onDisconnect,
null);
}
public SolrZkClient(
String zkServerAddress,
int zkClientTimeout,
int clientConnectTimeout,
- ZkClientConnectionStrategy strat,
+ ZkCredentialsProvider zkCredentialsProvider,
+ ACLProvider aclProvider,
final OnReconnect onReconnect,
- BeforeReconnect beforeReconnect,
- ZkACLProvider zkACLProvider,
+ OnDisconnect onDisconnect,
IsClosed higherLevelIsClosed) {
this.zkServerAddress = zkServerAddress;
-this.higherLevelIsClosed = higherLevelIsClosed;
-if (strat == null) {
- strat = new DefaultConnectionStrategy();
+String chroot, zkHost;
+int chrootIndex = zkServerAddress.indexOf('/');
+if (chrootIndex == -1) {
+ zkHost = zkServerAddress;
+ chroot = null;
+} else if (chrootIndex == zkServerAddress.length() - 1) {
+ zkHost = zkServerAddress.substring(0, zkServerAddress.length() - 1);
+ chroot = null;
+} else {
+ zkHost = zkServerAddress.substring(0, chrootIndex);
+ chroot = zkServerAddress.substring(chrootIndex + 1);
}
-this.zkClientConnectionStrategy = strat;
+this.higherLevelIsClosed = higherLevelIsClosed;
-if (!strat.hasZkCredentialsToAddAutomatically()) {
- ZkCredentialsProvider zkCredentialsToAddAutomatically =
- createZkCredentialsToAddAutomatically();
-
strat.setZkCredentialsToAddAutomatically(zkCredentialsToAddAutomatically);
+if (zkCredentialsProvider == null) {
+ zkCredentialsProvider = createZkCredentialsToAddAutomatically();
+}
+if (aclProvider == null) {
+ aclProvider = createACLProvider();
+}
+if (chroot != null && aclProvider instanceof SecurityAwareZkACLProvider) {
+ this.aclProvider =
((SecurityAwareZkACLProvider)aclProvider).withChroot(chroot);
+} else {
+ this.aclProvider = aclProvider;
}
this.zkClientTimeout = zkClientTimeout;
-// we must retry at least as long as the session timeout
-zkCmdExecutor =
-new ZkCmdExecutor(
-zkClientTimeout,
-new IsClosed() {
-
- @Override
- public boolean isClosed() {
-return SolrZkClient.this.isClosed();
- }
-});
-connManager =
-new ConnectionManager(
-"ZooKeeperConnection Watcher:" + zkServerAddress,
-this,
-zkServerAddress,
-strat,
-onReconnect,
-beforeReconnect,
-new IsClosed() {
-
- @Override
- public boolean isClosed() {
-return SolrZkClient.this.isClosed();
- }
-});
-try {
- strat.connect(
- zkServerAddress,
- zkClientTimeout,
- wrapWatcher(connManager),
- zooKeeper -> {
-SolrZooKeeper oldKeeper = keeper;
-keeper = zooKeeper;
-try {
- closeKeeper(oldKeeper);
-} finally {
- if (isClosed) {
-// we may have been closed
-closeKeeper(SolrZkClient.this.keeper);
- }
-}
- });
-} catch (Exception e) {
- connManager.close();
- if (keeper != null) {
-try {
- keeper.close();
-} catch (InterruptedException e1) {
- Thread.currentThread().interrupt();
-}
- }
- throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
-}
+RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
+var clientBuilder = CuratorFrameworkFactory.builder()
+.ensembleProvider(new FixedEnsembleProvider(zkHost))
+.namespace(chroot)
+.sessionTimeoutMs(zkClientTimeout)
+.connectionTimeoutMs(clientConnectTimeout)
+.aclProvider(this.aclProvider)
+.authorization(zkCredentialsProvider.getCredentials())
+.retryPolicy(retryPolicy);
+client = clientBuilder.build();
Review Comment:
I recently worked on an experimental hack for some days on 8x to have the
Overseer use Curator for elections. One thing that I got stuck on was that
Solr's tests were finding some threads linger
[GitHub] [solr] dsmiley commented on a diff in pull request #1374: SOLR-16623:SolrClientTestRule for JettySolrRunnerV2
dsmiley commented on code in PR #1374:
URL: https://github.com/apache/solr/pull/1374#discussion_r1118019036
##
solr/core/src/test/org/apache/solr/request/TestRemoteStreaming.java:
##
@@ -116,7 +116,7 @@ public void testNoUrlAccess() throws Exception {
SolrQuery query = new SolrQuery();
query.setQuery("*:*"); // for anything
query.add("stream.url", makeDeleteAllUrl());
-try (SolrClient solrClient = createNewSolrClient()) {
+try (SolrClient solrClient = getSolrClient()) {//TODO Close the client
Review Comment:
This TODO is already handled :-). If you don't recognize this, then learn
about Java's "try-with-resources" pattern.
##
solr/test-framework/src/java/org/apache/solr/SolrJettyTestBase.java:
##
@@ -138,17 +142,15 @@ public static void afterSolrJettyTestBase() throws
Exception {
solrClientTestRule.reset();
}
- /**
- * Create a new solr client. If createJetty was called, a http
implementation will be created,
- * otherwise an embedded implementation will be created. Subclasses should
override for other
- * options.
- */
- public SolrClient createNewSolrClient() {
-return solrClientTestRule.getSolrClient();
+ public synchronized SolrClient getSolrClient() {
+if (getClient() == null) {
Review Comment:
Why would this ever return null? Why is it synchronized?
##
solr/test-framework/src/java/org/apache/solr/SolrJettyTestBase.java:
##
@@ -129,6 +129,10 @@ public static JettySolrRunner getJetty() {
return solrClientTestRule.getJetty();
}
+ public static SolrClient getClient() {
Review Comment:
I don't think we need to add new API methods to this class that didn't
already exist
##
solr/test-framework/src/java/org/apache/solr/util/SolrJettyTestRule.java:
##
@@ -31,18 +31,13 @@
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
+// TODO write javadocs
public class SolrJettyTestRule extends SolrClientTestRule {
private static final Logger log =
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
- private SolrClient client = null;
private JettySolrRunner jetty;
+ private SolrClient client = null;
Review Comment:
Why is "client" its own field yet we've got this "clients" map?
##
solr/test-framework/src/java/org/apache/solr/util/SolrJettyTestRule.java:
##
@@ -75,9 +70,22 @@ protected void after() {
}
client = null;
}
+
+for (SolrClient solrClient : clients.values()) {
Review Comment:
The sequence of actions in a lifecycle method (and this is one) can
sometimes matter. Do things in reverse order in a closing/after type of
method. Thus clients should be closed and *then* close Jetty. It's the
reverse order from starting.
##
solr/test-framework/src/java/org/apache/solr/SolrJettyTestBase.java:
##
@@ -138,17 +142,15 @@ public static void afterSolrJettyTestBase() throws
Exception {
solrClientTestRule.reset();
}
- /**
- * Create a new solr client. If createJetty was called, a http
implementation will be created,
- * otherwise an embedded implementation will be created. Subclasses should
override for other
- * options.
- */
- public SolrClient createNewSolrClient() {
-return solrClientTestRule.getSolrClient();
+ public synchronized SolrClient getSolrClient() {
+if (getClient() == null) {
+ return solrClientTestRule.getSolrClient();
+}
+return getClient();
}
Review Comment:
When the method fundamentally changes away from using fields on this class
to calling the rule, it no longer needs to be synchronized because the rule's
getSolrClient is thread-safe.
also, don't see why getClient exists nor why it would return null.
##
solr/test-framework/src/java/org/apache/solr/util/SolrJettyTestRule.java:
##
@@ -94,33 +102,37 @@ public void startSolr(Path solrHome) {
public void startSolr(Path solrHome, Properties nodeProperties, JettyConfig
jettyConfig) {
-jetty = new JettySolrRunner(solrHome.toString(), nodeProperties,
jettyConfig);
-try {
- jetty.start();
-} catch (RuntimeException e) {
- throw e;
-} catch (Exception e) {
- throw new RuntimeException(e);
+if (jetty == null) {
+
+ jetty = new JettySolrRunner(solrHome.toString(), nodeProperties,
jettyConfig);
+ try {
+jetty.start();
+ } catch (RuntimeException e) {
+throw e;
+ } catch (Exception e) {
+throw new RuntimeException(e);
+ }
+ int port = jetty.getLocalPort();
+ log.info("Jetty Assigned Port#{}", port);
+ adminClient = getHttpSolrClient(jetty.getBaseUrl().toString());
}
-int port = jetty.getLocalPort();
-log.info("Jetty Assigned Port#{}", port);
-adminClient = getHttpSolrClient(jetty.getBaseUrl().toString());
}
public JettySolrRunner getJetty() {
if (jetty == null) throw new IllegalStateException("Jetty
[jira] [Updated] (SOLR-16681) Replacement field via fl doesn't work since 9.1
[
https://issues.apache.org/jira/browse/SOLR-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-16681:
Attachment: image-2023-02-26-09-48-31-974.png
> Replacement field via fl doesn't work since 9.1
> ---
>
> Key: SOLR-16681
> URL: https://issues.apache.org/jira/browse/SOLR-16681
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: image-2023-02-26-09-48-31-974.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User reported a use case which were working before 9.1 but not anymore.
> The point is to logically replace a field (hereby it's {{id}} but it might
> behave same for any other)
> {{fl=old_id:id,id:new_id}}
> I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
> [reproducer|https://github.com/apache/solr/pull/1384]. see the link. [Then I
> applied
> it|https://github.com/mkhludnev/solr/tree/SOLR-16681-proves-work-before] to
> revision preceding
> [SOLR-9376|https://github.com/mkhludnev/solr/commit/6ff81312607dd5d33f87dc52aed9d52938dc6883#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
> and test passed. For me it seems like:
> - Solr behave like described before, but does not after SOLR-9376.
> - Should we reproduce this behavior or we can suggest a workaround?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16681) Replacement field via fl doesn't work since 9.1
[
https://issues.apache.org/jira/browse/SOLR-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-16681:
Attachment: image-2023-02-26-09-48-59-323.png
> Replacement field via fl doesn't work since 9.1
> ---
>
> Key: SOLR-16681
> URL: https://issues.apache.org/jira/browse/SOLR-16681
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: image-2023-02-26-09-48-31-974.png,
> image-2023-02-26-09-48-59-323.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User reported a use case which were working before 9.1 but not anymore.
> The point is to logically replace a field (hereby it's {{id}} but it might
> behave same for any other)
> {{fl=old_id:id,id:new_id}}
> I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
> [reproducer|https://github.com/apache/solr/pull/1384]. see the link. [Then I
> applied
> it|https://github.com/mkhludnev/solr/tree/SOLR-16681-proves-work-before] to
> revision preceding
> [SOLR-9376|https://github.com/mkhludnev/solr/commit/6ff81312607dd5d33f87dc52aed9d52938dc6883#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
> and test passed. For me it seems like:
> - Solr behave like described before, but does not after SOLR-9376.
> - Should we reproduce this behavior or we can suggest a workaround?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16681) Replacement field via fl doesn't work since 9.1
[
https://issues.apache.org/jira/browse/SOLR-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17693591#comment-17693591
]
Mikhail Khludnev commented on SOLR-16681:
-
Despite initial test can't really reproduce the problem, I see really weird
behavior. It's {{main}} build locally.
!image-2023-02-26-09-48-31-974.png!
!image-2023-02-26-09-48-59-323.png!
> Replacement field via fl doesn't work since 9.1
> ---
>
> Key: SOLR-16681
> URL: https://issues.apache.org/jira/browse/SOLR-16681
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: image-2023-02-26-09-48-31-974.png,
> image-2023-02-26-09-48-59-323.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User reported a use case which were working before 9.1 but not anymore.
> The point is to logically replace a field (hereby it's {{id}} but it might
> behave same for any other)
> {{fl=old_id:id,id:new_id}}
> I'd say it's a kind of {{{}$mv new_id id{}}}. I've made a simple
> [reproducer|https://github.com/apache/solr/pull/1384]. see the link. [Then I
> applied
> it|https://github.com/mkhludnev/solr/tree/SOLR-16681-proves-work-before] to
> revision preceding
> [SOLR-9376|https://github.com/mkhludnev/solr/commit/6ff81312607dd5d33f87dc52aed9d52938dc6883#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
> and test passed. For me it seems like:
> - Solr behave like described before, but does not after SOLR-9376.
> - Should we reproduce this behavior or we can suggest a workaround?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
