[jira] [Resolved] (SOLR-16593) Redundant fields are present in the replica object of state.json
[
https://issues.apache.org/jira/browse/SOLR-16593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-16593.
---
Fix Version/s: 9.2
Resolution: Fixed
> Redundant fields are present in the replica object of state.json
>
>
> Key: SOLR-16593
> URL: https://issues.apache.org/jira/browse/SOLR-16593
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 9.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following is the new state,json
> {quote}{"shards":{"shard0":{
> "shard_range":"7c00-7c1f",
> "replicas":{"core_node0":{
> "core":"replicacore",
> "leader":"true",
> "core_node_name":"test1_shard0_replica_n0",
> "node_name":"localhost:8983_solr",
> "base_url":"https://localhost;,
> "state":"active",
> "collection":"test1",
> "shard":"shard0",
> "type":"NRT",
> "force_set_state":"false"}},
> "state":"active"}}}
> {quote}
> The following fields are added and they look redundant to me
> # "collection":"test1"
> # "shard":"shard0"
> # "core_node_name":"test1_shard0_replica_n0"
--
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-16593) Redundant fields are present in the replica object of state.json
[
https://issues.apache.org/jira/browse/SOLR-16593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17678107#comment-17678107
]
ASF subversion and git services commented on SOLR-16593:
Commit a8b9d046ddcca4e79137c28407f9e332f056f26c in solr's branch
refs/heads/branch_9x from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=a8b9d046ddc ]
SOLR-16593 : Redundant fields are present in the replica object of state.json
(#1293)
> Redundant fields are present in the replica object of state.json
>
>
> Key: SOLR-16593
> URL: https://issues.apache.org/jira/browse/SOLR-16593
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following is the new state,json
> {quote}{"shards":{"shard0":{
> "shard_range":"7c00-7c1f",
> "replicas":{"core_node0":{
> "core":"replicacore",
> "leader":"true",
> "core_node_name":"test1_shard0_replica_n0",
> "node_name":"localhost:8983_solr",
> "base_url":"https://localhost;,
> "state":"active",
> "collection":"test1",
> "shard":"shard0",
> "type":"NRT",
> "force_set_state":"false"}},
> "state":"active"}}}
> {quote}
> The following fields are added and they look redundant to me
> # "collection":"test1"
> # "shard":"shard0"
> # "core_node_name":"test1_shard0_replica_n0"
--
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-16593) Redundant fields are present in the replica object of state.json
[
https://issues.apache.org/jira/browse/SOLR-16593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17678097#comment-17678097
]
ASF subversion and git services commented on SOLR-16593:
Commit 13857ba4dd7b0ff651903de45ac03c7d174e952c in solr's branch
refs/heads/main from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=13857ba4dd7 ]
SOLR-16593 : Redundant fields are present in the replica object of state.json
(#1293)
> Redundant fields are present in the replica object of state.json
>
>
> Key: SOLR-16593
> URL: https://issues.apache.org/jira/browse/SOLR-16593
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following is the new state,json
> {quote}{"shards":{"shard0":{
> "shard_range":"7c00-7c1f",
> "replicas":{"core_node0":{
> "core":"replicacore",
> "leader":"true",
> "core_node_name":"test1_shard0_replica_n0",
> "node_name":"localhost:8983_solr",
> "base_url":"https://localhost;,
> "state":"active",
> "collection":"test1",
> "shard":"shard0",
> "type":"NRT",
> "force_set_state":"false"}},
> "state":"active"}}}
> {quote}
> The following fields are added and they look redundant to me
> # "collection":"test1"
> # "shard":"shard0"
> # "core_node_name":"test1_shard0_replica_n0"
--
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] noblepaul merged pull request #1293: SOLR-16593 : Redundant fields are present in the replica object of state.json
noblepaul merged PR #1293: URL: https://github.com/apache/solr/pull/1293 -- 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] [Created] (SOLR-16623) SolrClientTestRule for JettySolrRunner
David Smiley created SOLR-16623: --- Summary: SolrClientTestRule for JettySolrRunner Key: SOLR-16623 URL: https://issues.apache.org/jira/browse/SOLR-16623 Project: Solr Issue Type: Sub-task Components: Tests Reporter: David Smiley (Sub-Task) Add a subclass of SolrClientTestRule (created in a sibling issue) for JettySolrRunner. Convert SolrJettyTestBase to use it, which contains some useful logic already that might migrate into such a rule. -- 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 #1218: SOLR-16573:SolrClientTestRule for EmbeddedSolrServer
dsmiley commented on code in PR #1218:
URL: https://github.com/apache/solr/pull/1218#discussion_r1073134160
##
solr/test-framework/src/java/org/apache/solr/util/EmbeddedSolrServerTestRule.java:
##
@@ -0,0 +1,199 @@
+/*
+ * 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 java.io.IOException;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import org.apache.lucene.tests.util.LuceneTestCase;
+import org.apache.solr.client.solrj.SolrServerException;
+import org.apache.solr.client.solrj.embedded.EmbeddedSolrServer;
+import org.apache.solr.client.solrj.impl.HttpClientUtil;
+import org.apache.solr.client.solrj.request.CoreAdminRequest;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.core.NodeConfig;
+import org.apache.solr.core.SolrXmlConfig;
+import org.apache.solr.update.UpdateShardHandlerConfig;
+
+/** TODO NOCOMMIT document */
+public class EmbeddedSolrServerTestRule extends SolrClientTestRule {
+
+ private static final String CORE_DIR_PROP = "coreRootDirectory";
+ private EmbeddedSolrServer adminClient = null;
+ private EmbeddedSolrServer client = null;
+ private CoreContainer container = null;
+
+ private boolean clearCoreDirSysProp = false;
+
+ public EmbeddedSolrServer getAdminClient() {
+return adminClient;
+ }
+
+ public void startSolr(Path solrHome) {
+NodeConfig nodeConfig;
+if (Files.exists(solrHome.resolve(SolrXmlConfig.SOLR_XML_FILE))) {
+ // existing solr.xml; perhaps not recommended for new/most tests
+
+ // solr.xml coreRootDirectory is best set to a temp directory in a test
so that
+ // (a) we don't load existing cores
+ // Because it's better for tests to explicitly create cores.
+ // (b) we don't write data in the test to a likely template directory
+ // But a test can insist on something if it sets the property.
+ if (System.getProperty(CORE_DIR_PROP) == null) {
+clearCoreDirSysProp = true;
+System.setProperty(CORE_DIR_PROP,
LuceneTestCase.createTempDir("cores").toString());
Review Comment:
I realized we don't need to set this as a System Property, we can do so in
an ad-hoc Properties instance that we pass below to the 2nd arg of
`fromSolrHome`. That will be cleaner.
--
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 pull request #1243: SOLR-16591 Make SolrCores pluggable.
dsmiley commented on PR #1243: URL: https://github.com/apache/solr/pull/1243#issuecomment-1386457707 I plan to commit in a couple days if I don't hear to the contrary. -- 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 pull request #1243: SOLR-16591 Make SolrCores pluggable.
dsmiley commented on PR #1243: URL: https://github.com/apache/solr/pull/1243#issuecomment-1386457113 I marked the pertinent classes deprecated, added a note about this in the upgrade notes, and added this CHANGES.txt entry: > SOLR-16591: The "Transient Cores" feature is now deprecated. In solr.xml "\" no longer works; it wasn't documented either. Some internals were changed as well to simplify the standard case of having no transient cores. (David Smiley) Obviously the title & description of the JIRA issue (and this PR) should change accordingly. -- 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] gerlowskija commented on pull request #1286: SOLR-16615: Reuse Jersey apps for cores with the same configset
gerlowskija commented on PR #1286: URL: https://github.com/apache/solr/pull/1286#issuecomment-1386285201 Hey @risdenk : I was hoping to gear up to merge, but see you still technically have an outstanding "change requested" on this PR. 99% sure this was the 'Suggested Change' to fix precommit that I accepted as-is, but I didn't want to assume in case you had something else you'd intended to mention? Anything else you want to see here? If not I'll merge in a few days! -- 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-16438) Shard split should be able to set preferred leaders on other replicas
[
https://issues.apache.org/jira/browse/SOLR-16438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677926#comment-17677926
]
Houston Putman commented on SOLR-16438:
---
{{SplitShardTest.testConcurrentSplitThreeHostsRepFactorTwo()}} (which uses the
preferred leaders option) is still failing at a rate of 12%
> Shard split should be able to set preferred leaders on other replicas
> -
>
> Key: SOLR-16438
> URL: https://issues.apache.org/jira/browse/SOLR-16438
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Bruno Roustant
>Assignee: Bruno Roustant
>Priority: Major
> Fix For: 9.2
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, shard split always create a first replica for each sub-shard on
> the current host. Then it creates other replicas and their corresponding
> sub-shards are in RECOVERY state. The effect is that the first replica (on
> the current host) is always the leader, meaning that if the sub-shards are
> split themselves, their sub-sub-shards leaders are also on the same host.
> This can lead to very unbalanced situation where the same host is the leader
> for a whole set of shards.
> A solution to distribute evenly the leaders is to flag some other replicas
> with the preferredLeader property during the split. Then a rebalance-leaders
> command can elect the appropriate leaders. If we do that for each split, then
> all the sub-shards have their leaders correctly balanced.
> To go further, we can improve CollectionsHandler#CollectionOperation to
> support combined operations. That way a CollectionOperation#SPLITSHARD_OP can
> trigger a split op, then a wait for split completion op, and then a rebalance
> leaders op.
--
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-15616) Allow thread metrics to be cached
[ https://issues.apache.org/jira/browse/SOLR-15616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677903#comment-17677903 ] Ishan Chattopadhyaya commented on SOLR-15616: - Good idea, I'll add the "Sec" for extra clarity. Thanks for the quick review. > Allow thread metrics to be cached > - > > Key: SOLR-15616 > URL: https://issues.apache.org/jira/browse/SOLR-15616 > Project: Solr > Issue Type: Improvement > Components: metrics >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-15616-2.patch, SOLR-15616-9x.patch, > SOLR-15616.patch, SOLR-15616.patch > > > Computing JVM metrics for threads can be expensive, and we should provide > option to users to avoid doing so on every call to the metrics API > (group=jvm). -- 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-12779) Force field/term centric matching mode for multi-term synonyms with sow=false
[
https://issues.apache.org/jira/browse/SOLR-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677902#comment-17677902
]
Rudi Seitz commented on SOLR-12779:
---
Linking to SOLR-16594 which contains a proposal for addressing this issue.
> Force field/term centric matching mode for multi-term synonyms with sow=false
> -
>
> Key: SOLR-12779
> URL: https://issues.apache.org/jira/browse/SOLR-12779
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 8.0
>Reporter: Amrit Sarkar
>Priority: Major
>
> As Doug Turnbull pointed out on the solr-user mailing list:
> [https://lists.apache.org/thread.html/27590a2d8598be515b24f47f7912e074d2010910242cfdeb1fcd655d%40%3Csolr-user.lucene.apache.org%3E]
> (recommended reading, especially for his discussion of the limitations of
> the new sow=false request parameter), sow=false changes the queries edismax
> produces over multiple fields when any of the fields’ query-time analysis
> differs from the other fields’, e.g. if one field’s analyzer removes
> stopwords when another field’s doesn’t. In this case, rather than a
> dismax-query-per-whitespace-separated-term (edismax’s behavior when
> sow=true), a dismax query per field is produced. This can change results in
> general, but quite significantly when combined with the mm (min-should-match)
> request parameter: since min-should-match applies per field instead of per
> term, missing terms in one field’s analysis won’t disqualify docs from
> matching. E.g. query “Terminator 100” with request param “mm=100%” against
> both a title (text) field and a run_length (integer) field will result in the
> following queries:
> When sow=true:
> {code:java}
> +(DisjunctionMaxQuery((title:terminator))
> DisjunctionMaxQuery((run_length:[100 TO 100] | title:100)))~2{code}
> When sow=false:
> {code:java}
> +DisjunctionMaxQuery((run_length:[100 TO 100] | ((title:terminator
> title:100)~2))){code}
> In the above scenario, when sow=true (and in versions of Solr before 6.5),
> “terminator” must appear in documents in order to produce a match. But when
> sow=false, a document can match if its run_length field is 100, even when the
> title does not contain “terminator”.
> It is good to have an option to force term centric or query-centric matching
> at query parsing; so that expected behavior can be achieved; discussed under
> [http://lucene.472066.n3.nabble.com/Split-on-whitespace-parameter-doubt-td4404185.html].
--
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-15616) Allow thread metrics to be cached
[ https://issues.apache.org/jira/browse/SOLR-15616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677899#comment-17677899 ] Andrzej Bialecki commented on SOLR-15616: - LGTM, thanks for seeing this through, Ishan! One minor suggestion: since the interval is expressed in seconds (whereas often other intervals are expressed in millis) maybe we should use `threadIntervalSec` or something like that? I leave it up to you - the docs say it's in seconds but if it's in the name then it's self-explanatory. > Allow thread metrics to be cached > - > > Key: SOLR-15616 > URL: https://issues.apache.org/jira/browse/SOLR-15616 > Project: Solr > Issue Type: Improvement > Components: metrics >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-15616-2.patch, SOLR-15616-9x.patch, > SOLR-15616.patch, SOLR-15616.patch > > > Computing JVM metrics for threads can be expensive, and we should provide > option to users to avoid doing so on every call to the metrics API > (group=jvm). -- 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] noblepaul commented on pull request #1210: SOLR-16347: Skip JerseyApp creation when v2 disabled
noblepaul commented on PR #1210: URL: https://github.com/apache/solr/pull/1210#issuecomment-1385915397 @gerlowskija we should keep this `disabled` by default so that performance testing is not blocked -- 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-15616) Allow thread metrics to be cached
[ https://issues.apache.org/jira/browse/SOLR-15616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-15616: Attachment: SOLR-15616-2.patch Status: Open (was: Open) Changed the caching config as a bean, as per your suggest, [~ab]. Can you please review? > Allow thread metrics to be cached > - > > Key: SOLR-15616 > URL: https://issues.apache.org/jira/browse/SOLR-15616 > Project: Solr > Issue Type: Improvement > Components: metrics >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-15616-2.patch, SOLR-15616-9x.patch, > SOLR-15616.patch, SOLR-15616.patch > > > Computing JVM metrics for threads can be expensive, and we should provide > option to users to avoid doing so on every call to the metrics API > (group=jvm). -- 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] magibney merged pull request #1291: buildAndPushRelease should optionally pause before assembleRelease
magibney merged PR #1291: URL: https://github.com/apache/solr/pull/1291 -- 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] magibney merged pull request #1290: releaseWizard: allow explicitly setting manifest.mf userid (e.g., to apache id)
magibney merged PR #1290: URL: https://github.com/apache/solr/pull/1290 -- 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-16622) Replicas don't come up active after node restart
[
https://issues.apache.org/jira/browse/SOLR-16622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677868#comment-17677868
]
Michael Gibney commented on SOLR-16622:
---
Thanks for this extra context, it's really helpful.
{quote}this just shows that our testing is inadequate at the moment{quote}
That makes sense broadly, IMO with some caveats (below). To state the obvious:
these are basically integration tests, and by nature are going to be difficult
to reproduce reliably, no matter how we proceed.
On the one hand I agree it is fair to characterize this particular case as a
functional regression -- on the other hand "our testing is inadequate" could
easily be read as suggesting that existing unit tests and bats integration
tests should do a better job of covering these types of issues, which I think
would be misleading given the inherent challenges involved with regularly
running integration tests. Really, the existing test suite is simply not
designed to catch these kinds of "integration test" issues, and even "bats"
integration tests would be difficult to adapt to serve the purpose of catching
issues that only crop up when running at scale.
"Straw man" argument: we could just lean in to periodic benchmarks helping to
catch these types of issues. The overhead of running integration tests at scale
would be significant. Even if the original intention of periodic benchmarks is
to evaluate performance, it may be ok (not really a problem) that we end up
catching some "integration test"-style issues as a consequence. (to be clear,
I'm kinda just thinking out loud; neither assuming you agree nor disagree,
Ishan!).
> Replicas don't come up active after node restart
>
>
> Key: SOLR-16622
> URL: https://issues.apache.org/jira/browse/SOLR-16622
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 9.1.1
>
> Attachments: Screenshot from 2023-01-17 15-03-05.png
>
>
> While benchmarking for performance, we saw a sharp change in the graphs:
> https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725
> Turns out there was a commit (SOLR-16414) that escaped all testing and caused
> a regression where restarted nodes didn't have the replicas coming up as
> active.
> This affects 9.1 release, so opening a new JIRA issue to track it.
> Here's how to reproduce it:
> {code}
> git clone https://github.com/fullstorydev/solr-bench
> cd solr-bench
> # prerequisites on ubuntu:
> sudo apt install openjdk-11-jdk
> sudo apt install wget unzip zip ant ivy lsof git netcat make maven jq
> # this is a patch to comment out the cleanup/final shutdown
> wget https://termbin.com/yuu95
> git apply yuu95
> mvn clean compile assembly:single
> ./cleanup.sh && ./stress.sh -c aa4f3d98ab19c201e7f3c74cd14c99174148616d
> suites/stress-facets-local.json
> {code}
> If the 95th percentile is <10 or so, we have a problem. It should be >300 or
> so. Since, we disabled cleanup, we can hit http://localhost:5/solr/ to
> open Solr UI. In this case, I see that querying to the ecommerce-events
> collection shows shard2 is down.
--
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-14336) Warn users running old version of Solr
[ https://issues.apache.org/jira/browse/SOLR-14336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677843#comment-17677843 ] Houston Putman commented on SOLR-14336: --- Yeah I think this is perfect with Ishan's suggestion of "Please consider upgrading." > Warn users running old version of Solr > -- > > Key: SOLR-14336 > URL: https://issues.apache.org/jira/browse/SOLR-14336 > Project: Solr > Issue Type: New Feature > Components: Admin UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Attachments: Skjermbilde 2023-01-17 kl. 15.25.49.png > > Time Spent: 10m > Remaining Estimate: 0h > > There are obviously many very old Solr installs out there. People are still > reporting issues for Solr 4.x and 5.x. This is a proposal that Solr will > print a warning in the logs and display a warning in the Admin UI Dashboard > when running a (probably) outdated version. > I do not aim to "call home" to Apache to check versions, but instead parse > release date from 'solr-impl-version' string and warn if more than 1 year > old. That should be very conservative as there will almost certainly be a > handful new releases, with potential security fixes. -- 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-14336) Warn users running old version of Solr
[ https://issues.apache.org/jira/browse/SOLR-14336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677810#comment-17677810 ] Ishan Chattopadhyaya commented on SOLR-14336: - Lets add a "Please"? > Warn users running old version of Solr > -- > > Key: SOLR-14336 > URL: https://issues.apache.org/jira/browse/SOLR-14336 > Project: Solr > Issue Type: New Feature > Components: Admin UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Attachments: Skjermbilde 2023-01-17 kl. 15.25.49.png > > Time Spent: 10m > Remaining Estimate: 0h > > There are obviously many very old Solr installs out there. People are still > reporting issues for Solr 4.x and 5.x. This is a proposal that Solr will > print a warning in the logs and display a warning in the Admin UI Dashboard > when running a (probably) outdated version. > I do not aim to "call home" to Apache to check versions, but instead parse > release date from 'solr-impl-version' string and warn if more than 1 year > old. That should be very conservative as there will almost certainly be a > handful new releases, with potential security fixes. -- 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-16622) Replicas don't come up active after node restart
[
https://issues.apache.org/jira/browse/SOLR-16622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya updated SOLR-16622:
Description:
While benchmarking for performance, we saw a sharp change in the graphs:
https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725
Turns out there was a commit (SOLR-16414) that escaped all testing and caused a
regression where restarted nodes didn't have the replicas coming up as active.
This affects 9.1 release, so opening a new JIRA issue to track it.
Here's how to reproduce it:
{code}
git clone https://github.com/fullstorydev/solr-bench
cd solr-bench
# prerequisites on ubuntu:
sudo apt install openjdk-11-jdk
sudo apt install wget unzip zip ant ivy lsof git netcat make maven jq
# this is a patch to comment out the cleanup/final shutdown
wget https://termbin.com/yuu95
git apply yuu95
mvn clean compile assembly:single
./cleanup.sh && ./stress.sh -c aa4f3d98ab19c201e7f3c74cd14c99174148616d
suites/stress-facets-local.json
{code}
If the 95th percentile is <10 or so, we have a problem. It should be >300 or
so. Since, we disabled cleanup, we can hit http://localhost:5/solr/ to open
Solr UI. In this case, I see that querying to the ecommerce-events collection
shows shard2 is down.
was:
While benchmarking for performance, we saw a sharp change in the graphs:
https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725
Turns out there was a commit (SOLR-16414) that escaped all testing and caused a
regression where restarted nodes didn't have the replicas coming up as active.
This affects 9.1 release, so opening a new JIRA issue to track it.
> Replicas don't come up active after node restart
>
>
> Key: SOLR-16622
> URL: https://issues.apache.org/jira/browse/SOLR-16622
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 9.1.1
>
> Attachments: Screenshot from 2023-01-17 15-03-05.png
>
>
> While benchmarking for performance, we saw a sharp change in the graphs:
> https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725
> Turns out there was a commit (SOLR-16414) that escaped all testing and caused
> a regression where restarted nodes didn't have the replicas coming up as
> active.
> This affects 9.1 release, so opening a new JIRA issue to track it.
> Here's how to reproduce it:
> {code}
> git clone https://github.com/fullstorydev/solr-bench
> cd solr-bench
> # prerequisites on ubuntu:
> sudo apt install openjdk-11-jdk
> sudo apt install wget unzip zip ant ivy lsof git netcat make maven jq
> # this is a patch to comment out the cleanup/final shutdown
> wget https://termbin.com/yuu95
> git apply yuu95
> mvn clean compile assembly:single
> ./cleanup.sh && ./stress.sh -c aa4f3d98ab19c201e7f3c74cd14c99174148616d
> suites/stress-facets-local.json
> {code}
> If the 95th percentile is <10 or so, we have a problem. It should be >300 or
> so. Since, we disabled cleanup, we can hit http://localhost:5/solr/ to
> open Solr UI. In this case, I see that querying to the ecommerce-events
> collection shows shard2 is down.
--
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-16622) Replicas don't come up active after node restart
[ https://issues.apache.org/jira/browse/SOLR-16622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677809#comment-17677809 ] Ishan Chattopadhyaya commented on SOLR-16622: - I think all this just shows that our testing is inadequate at the moment. The periodic benchmarks caught it, but it was there more for performance benchmarks than such glaring functional regressions. However, it also exposed a problem with solr-bench: instead of reporting the failed queries as failures, they were reported as fast queries (problem with exception handling). I'll address that soon. > Replicas don't come up active after node restart > > > Key: SOLR-16622 > URL: https://issues.apache.org/jira/browse/SOLR-16622 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 9.1.1 > > Attachments: Screenshot from 2023-01-17 15-03-05.png > > > While benchmarking for performance, we saw a sharp change in the graphs: > https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725 > Turns out there was a commit (SOLR-16414) that escaped all testing and caused > a regression where restarted nodes didn't have the replicas coming up as > active. > This affects 9.1 release, so opening a new JIRA issue to track it. -- 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-16622) Replicas don't come up active after node restart
[ https://issues.apache.org/jira/browse/SOLR-16622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677806#comment-17677806 ] Ishan Chattopadhyaya commented on SOLR-16622: - bq. I'm curious whether you have any insight into what the specific cause of the issue may have been? I can only attest to the effect of what I saw, haven't yet dug into what the problem actually was. The commit https://gitbox.apache.org/repos/asf?p=solr.git;h=97e5483cb6b (SOLR-16414) caused Solr nodes to come up in stress tests, but querying them was not possible because two of the three replicas (shard2 and shard3) were in down state. Also, additionally, there was PRS like structure to a non-PRS collection. !Screenshot from 2023-01-17 15-03-05.png! Since from the graphs we knew the problem was corrected by itself at a later point, all I had to do was to find the commit that fixed it (by looking at the graph). This was the first commit that fixed it: https://gitbox.apache.org/repos/asf?p=solr.git;h=1d7b7795cc7, so backported it. I manually tested that the state.json structure was proper as well. > Replicas don't come up active after node restart > > > Key: SOLR-16622 > URL: https://issues.apache.org/jira/browse/SOLR-16622 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 9.1.1 > > Attachments: Screenshot from 2023-01-17 15-03-05.png > > > While benchmarking for performance, we saw a sharp change in the graphs: > https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725 > Turns out there was a commit (SOLR-16414) that escaped all testing and caused > a regression where restarted nodes didn't have the replicas coming up as > active. > This affects 9.1 release, so opening a new JIRA issue to track it. -- 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] magibney commented on pull request #1291: buildAndPushRelease should optionally pause before assembleRelease
magibney commented on PR #1291:
URL: https://github.com/apache/solr/pull/1291#issuecomment-1385592060
Thanks, Kevin and Jan! I did a dry-run of this (and also #1290), and both
worked as intended. I'll merge and incorporate testing this out "in real life"
while building 9.1.1 RC2.
(It occurred to me: I'll probably change `str(input("[...]")` to be just
`input("[...]")` -- we're discarding the input anyway, so there's no point in
wrapping it with `str()`).
--
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-16622) Replicas don't come up active after node restart
[ https://issues.apache.org/jira/browse/SOLR-16622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-16622: Attachment: Screenshot from 2023-01-17 15-03-05.png > Replicas don't come up active after node restart > > > Key: SOLR-16622 > URL: https://issues.apache.org/jira/browse/SOLR-16622 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 9.1.1 > > Attachments: Screenshot from 2023-01-17 15-03-05.png > > > While benchmarking for performance, we saw a sharp change in the graphs: > https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725 > Turns out there was a commit (SOLR-16414) that escaped all testing and caused > a regression where restarted nodes didn't have the replicas coming up as > active. > This affects 9.1 release, so opening a new JIRA issue to track it. -- 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] [Comment Edited] (SOLR-16622) Replicas don't come up active after node restart
[ https://issues.apache.org/jira/browse/SOLR-16622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677800#comment-17677800 ] Ishan Chattopadhyaya edited comment on SOLR-16622 at 1/17/23 3:16 PM: -- bq. Why was this pushed directly to the release branch with no additional tests? Why is this ONLY pushed to branch_9_1 and not main or branch_9x first? This is a cherry-pick of 1d7b7795cc77ad6863832e3a87d144a68490ba06 from branch_9x (SOLR-16414) to the branch_9_1. Added a new issue instead of re-opening the SOLR-16414 for ease of tracking (since SOLR-16414 was already released in part). was (Author: ichattopadhyaya): bq. Why was this pushed directly to the release branch with no additional tests? Why is this ONLY pushed to branch_9_1 and not main or branch_9x first? This is a cherry-pick of 1d7b7795cc77ad6863832e3a87d144a68490ba06 from branch_9x (SOLR-16414) to the branch_9_1. Added a new issue instead of re-opening the SOLR-16414 for ease of tracking (since SOLR-16414 was already released). > Replicas don't come up active after node restart > > > Key: SOLR-16622 > URL: https://issues.apache.org/jira/browse/SOLR-16622 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 9.1.1 > > > While benchmarking for performance, we saw a sharp change in the graphs: > https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725 > Turns out there was a commit (SOLR-16414) that escaped all testing and caused > a regression where restarted nodes didn't have the replicas coming up as > active. > This affects 9.1 release, so opening a new JIRA issue to track it. -- 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] [Comment Edited] (SOLR-16622) Replicas don't come up active after node restart
[ https://issues.apache.org/jira/browse/SOLR-16622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677800#comment-17677800 ] Ishan Chattopadhyaya edited comment on SOLR-16622 at 1/17/23 3:15 PM: -- bq. Why was this pushed directly to the release branch with no additional tests? Why is this ONLY pushed to branch_9_1 and not main or branch_9x first? This is a cherry-pick of 1d7b7795cc77ad6863832e3a87d144a68490ba06 from branch_9x (SOLR-16414) to the branch_9_1. Added a new issue instead of re-opening the SOLR-16414 for ease of tracking (since SOLR-16414 was already released). was (Author: ichattopadhyaya): bq. Why was this pushed directly to the release branch with no additional tests? Why is this ONLY pushed to branch_9_1 and not main or branch_9x first? This is a cherry-pick of 1d7b7795cc77ad6863832e3a87d144a68490ba06 from branch_9x (SOLR-16414) to the branch_9_1. > Replicas don't come up active after node restart > > > Key: SOLR-16622 > URL: https://issues.apache.org/jira/browse/SOLR-16622 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 9.1.1 > > > While benchmarking for performance, we saw a sharp change in the graphs: > https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725 > Turns out there was a commit (SOLR-16414) that escaped all testing and caused > a regression where restarted nodes didn't have the replicas coming up as > active. > This affects 9.1 release, so opening a new JIRA issue to track it. -- 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-16622) Replicas don't come up active after node restart
[ https://issues.apache.org/jira/browse/SOLR-16622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677800#comment-17677800 ] Ishan Chattopadhyaya commented on SOLR-16622: - bq. Why was this pushed directly to the release branch with no additional tests? Why is this ONLY pushed to branch_9_1 and not main or branch_9x first? This is a cherry-pick of 1d7b7795cc77ad6863832e3a87d144a68490ba06 from branch_9x (SOLR-16414) to the branch_9_1. > Replicas don't come up active after node restart > > > Key: SOLR-16622 > URL: https://issues.apache.org/jira/browse/SOLR-16622 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 9.1.1 > > > While benchmarking for performance, we saw a sharp change in the graphs: > https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725 > Turns out there was a commit (SOLR-16414) that escaped all testing and caused > a regression where restarted nodes didn't have the replicas coming up as > active. > This affects 9.1 release, so opening a new JIRA issue to track it. -- 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] [Assigned] (SOLR-14336) Warn users running old version of Solr
[ https://issues.apache.org/jira/browse/SOLR-14336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned SOLR-14336: -- Assignee: Jan Høydahl > Warn users running old version of Solr > -- > > Key: SOLR-14336 > URL: https://issues.apache.org/jira/browse/SOLR-14336 > Project: Solr > Issue Type: New Feature > Components: Admin UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Attachments: Skjermbilde 2023-01-17 kl. 15.25.49.png > > Time Spent: 10m > Remaining Estimate: 0h > > There are obviously many very old Solr installs out there. People are still > reporting issues for Solr 4.x and 5.x. This is a proposal that Solr will > print a warning in the logs and display a warning in the Admin UI Dashboard > when running a (probably) outdated version. > I do not aim to "call home" to Apache to check versions, but instead parse > release date from 'solr-impl-version' string and warn if more than 1 year > old. That should be very conservative as there will almost certainly be a > handful new releases, with potential security fixes. -- 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-14336) Warn users running old version of Solr
[ https://issues.apache.org/jira/browse/SOLR-14336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677790#comment-17677790 ] Jan Høydahl commented on SOLR-14336: This is how it looks like (I forced it to display to get a screenshot, but the logic is >365 days). !Skjermbilde 2023-01-17 kl. 15.25.49.png|width=800! > Warn users running old version of Solr > -- > > Key: SOLR-14336 > URL: https://issues.apache.org/jira/browse/SOLR-14336 > Project: Solr > Issue Type: New Feature > Components: Admin UI >Reporter: Jan Høydahl >Priority: Major > Attachments: Skjermbilde 2023-01-17 kl. 15.25.49.png > > Time Spent: 10m > Remaining Estimate: 0h > > There are obviously many very old Solr installs out there. People are still > reporting issues for Solr 4.x and 5.x. This is a proposal that Solr will > print a warning in the logs and display a warning in the Admin UI Dashboard > when running a (probably) outdated version. > I do not aim to "call home" to Apache to check versions, but instead parse > release date from 'solr-impl-version' string and warn if more than 1 year > old. That should be very conservative as there will almost certainly be a > handful new releases, with potential security fixes. -- 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-14336) Warn users running old version of Solr
[ https://issues.apache.org/jira/browse/SOLR-14336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-14336: --- Attachment: Skjermbilde 2023-01-17 kl. 15.25.49.png > Warn users running old version of Solr > -- > > Key: SOLR-14336 > URL: https://issues.apache.org/jira/browse/SOLR-14336 > Project: Solr > Issue Type: New Feature > Components: Admin UI >Reporter: Jan Høydahl >Priority: Major > Attachments: Skjermbilde 2023-01-17 kl. 15.25.49.png > > Time Spent: 10m > Remaining Estimate: 0h > > There are obviously many very old Solr installs out there. People are still > reporting issues for Solr 4.x and 5.x. This is a proposal that Solr will > print a warning in the logs and display a warning in the Admin UI Dashboard > when running a (probably) outdated version. > I do not aim to "call home" to Apache to check versions, but instead parse > release date from 'solr-impl-version' string and warn if more than 1 year > old. That should be very conservative as there will almost certainly be a > handful new releases, with potential security fixes. -- 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] janhoy opened a new pull request, #1297: SOLR-14336 Warn users running old version of Solr
janhoy opened a new pull request, #1297: URL: https://github.com/apache/solr/pull/1297 https://issues.apache.org/jira/browse/SOLR-14336 This impl will simply parse release date from solr-impl string, count number of days old, and warn in Admin UI dashboard if older than a year. No warning in logs. -- 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-16622) Replicas don't come up active after node restart
[
https://issues.apache.org/jira/browse/SOLR-16622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677786#comment-17677786
]
Michael Gibney commented on SOLR-16622:
---
Thanks for catching this and backporting. I will prepare RC2 for 9.1.1 shortly.
{quote}Turns out there was a commit (SOLR-16414) that escaped all testing{quote}
To probe this a little bit: there were multiple commits on SOLR-16414; I'm
curious whether you have any insight into what the specific cause of the issue
may have been? Looking at the diff for the change that ended up fixing this
issue, I wonder if possibly [wrapping
exceptions|https://github.com/apache/solr/commit/deb9e243995#diff-5b63503605ede4384429e74d1fa0c410adc5da8f3246e8c36e49feff2f3ea692L2969-L2971]
may have messed with exception handling/retries?
> Replicas don't come up active after node restart
>
>
> Key: SOLR-16622
> URL: https://issues.apache.org/jira/browse/SOLR-16622
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 9.1.1
>
>
> While benchmarking for performance, we saw a sharp change in the graphs:
> https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725
> Turns out there was a commit (SOLR-16414) that escaped all testing and caused
> a regression where restarted nodes didn't have the replicas coming up as
> active.
> This affects 9.1 release, so opening a new JIRA issue to track it.
--
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-16622) Replicas don't come up active after node restart
[ https://issues.apache.org/jira/browse/SOLR-16622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677784#comment-17677784 ] Kevin Risden commented on SOLR-16622: - Why was this pushed directly to the release branch with no additional tests? Why is this ONLY pushed to branch_9_1 and not main or branch_9x first? https://issues.apache.org/jira/browse/SOLR-16414 was pushed to main and branch_9x. > Replicas don't come up active after node restart > > > Key: SOLR-16622 > URL: https://issues.apache.org/jira/browse/SOLR-16622 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 9.1.1 > > > While benchmarking for performance, we saw a sharp change in the graphs: > https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725 > Turns out there was a commit (SOLR-16414) that escaped all testing and caused > a regression where restarted nodes didn't have the replicas coming up as > active. > This affects 9.1 release, so opening a new JIRA issue to track it. -- 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] [Assigned] (SOLR-15772) More visible security warnings in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-15772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned SOLR-15772: -- Assignee: Jan Høydahl > More visible security warnings in Admin UI > -- > > Key: SOLR-15772 > URL: https://issues.apache.org/jira/browse/SOLR-15772 > Project: Solr > Issue Type: Improvement > Components: Admin UI, security, Security UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Attachments: Skjermbilde 2023-01-17 kl. 14.42.04.png, > security-panel.png, security-tab.png > > Time Spent: 10m > Remaining Estimate: 0h > > We recently got both a "Security" panel on the Admin UI Dashboard, and a > brand new "Security" tab/screen to edit security.json. This is cool. > !security-panel.png|width=300!!security-tab.png|width=700! > Now that we have APIs to check this staus, I propose that the Admin UI > displays prominent red warnings in the dashboard panel when security and/or > SSL is not enabled. This will supplement what is logged to solr.log today. -- 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-15772) More visible security warnings in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-15772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1761#comment-1761 ] Jan Høydahl commented on SOLR-15772: With suggested PR this will look like this on the dashboard if security is not enabled: !Skjermbilde 2023-01-17 kl. 14.42.04.png|width=600! I'd prefer an even more visible clue, but at least this is better than the current table with empty values. > More visible security warnings in Admin UI > -- > > Key: SOLR-15772 > URL: https://issues.apache.org/jira/browse/SOLR-15772 > Project: Solr > Issue Type: Improvement > Components: Admin UI, security, Security UI >Reporter: Jan Høydahl >Priority: Major > Attachments: Skjermbilde 2023-01-17 kl. 14.42.04.png, > security-panel.png, security-tab.png > > Time Spent: 10m > Remaining Estimate: 0h > > We recently got both a "Security" panel on the Admin UI Dashboard, and a > brand new "Security" tab/screen to edit security.json. This is cool. > !security-panel.png|width=300!!security-tab.png|width=700! > Now that we have APIs to check this staus, I propose that the Admin UI > displays prominent red warnings in the dashboard panel when security and/or > SSL is not enabled. This will supplement what is logged to solr.log today. -- 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-15772) More visible security warnings in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-15772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-15772: --- Attachment: Skjermbilde 2023-01-17 kl. 14.42.04.png > More visible security warnings in Admin UI > -- > > Key: SOLR-15772 > URL: https://issues.apache.org/jira/browse/SOLR-15772 > Project: Solr > Issue Type: Improvement > Components: Admin UI, security, Security UI >Reporter: Jan Høydahl >Priority: Major > Attachments: Skjermbilde 2023-01-17 kl. 14.42.04.png, > security-panel.png, security-tab.png > > Time Spent: 10m > Remaining Estimate: 0h > > We recently got both a "Security" panel on the Admin UI Dashboard, and a > brand new "Security" tab/screen to edit security.json. This is cool. > !security-panel.png|width=300!!security-tab.png|width=700! > Now that we have APIs to check this staus, I propose that the Admin UI > displays prominent red warnings in the dashboard panel when security and/or > SSL is not enabled. This will supplement what is logged to solr.log today. -- 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] janhoy opened a new pull request, #1296: SOLR-15772 More visible security warnings in Admin UI
janhoy opened a new pull request, #1296: URL: https://github.com/apache/solr/pull/1296 https://issues.apache.org/jira/browse/SOLR-15772 I know I should have chosen some other class to get `text-align: left` and not put the style on the div tag, but I was too lazy to investigate what class might do that for me... -- 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-16621) Admin UI fails to grant user permissions that have wildcard role
[
https://issues.apache.org/jira/browse/SOLR-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677753#comment-17677753
]
Jan Høydahl commented on SOLR-16621:
Plan to target 9.2 with this
> Admin UI fails to grant user permissions that have wildcard role
>
>
> Key: SOLR-16621
> URL: https://issues.apache.org/jira/browse/SOLR-16621
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Security UI
>Affects Versions: 9.1
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Admin UI has a Security Dashboard that requires the 'security-read'
> permission to view and the 'security-edit' permission to modify.
> It will display an error message if the user lacks these permission, based on
> a match of user's roles and the permission roles. This works fine.
> However, if any authenticated user is granted a permission through wildcard
> role, e.g.
> {code:java}
> "permissions": [ {"name": "security-read", "role": "*"}] {code}
> ...then the check fails since it does not understand wildcard roles.
> [~thelabdude]
--
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-16622) Replicas don't come up active after node restart
[ https://issues.apache.org/jira/browse/SOLR-16622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677744#comment-17677744 ] ASF subversion and git services commented on SOLR-16622: Commit f780d92f959f5811cf134c04447ee5616df18c43 in solr's branch refs/heads/branch_9_1 from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=solr.git;h=f780d92f959 ] SOLR-16622: CHANGES.txt > Replicas don't come up active after node restart > > > Key: SOLR-16622 > URL: https://issues.apache.org/jira/browse/SOLR-16622 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 9.1.1 > > > While benchmarking for performance, we saw a sharp change in the graphs: > https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725 > Turns out there was a commit (SOLR-16414) that escaped all testing and caused > a regression where restarted nodes didn't have the replicas coming up as > active. > This affects 9.1 release, so opening a new JIRA issue to track it. -- 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-16525) Periodic performance benchmarking
[ https://issues.apache.org/jira/browse/SOLR-16525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677743#comment-17677743 ] Ishan Chattopadhyaya commented on SOLR-16525: - Fixed the issue: SOLR-16622. Continuing with other testing now. > Periodic performance benchmarking > - > > Key: SOLR-16525 > URL: https://issues.apache.org/jira/browse/SOLR-16525 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: Screenshot from 2023-01-14 17-39-42.png, > image-2022-11-09-13-23-21-131.png, > logs-stress-facets-local.json-b9f5f9ffed8e0c1af679911db6af698d18ab8fe1.zip, > logs-stress-facets-local.json-ebc823a599160914f7f0f2694f64a53d9cd20268.zip, > periodic-benchmarks.odp, periodic-benchmarks.pdf > > > This issue is about periodic performance testing of Solr commits against > pre-written suites of performance tests. -- 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] [Resolved] (SOLR-16622) Replicas don't come up active after node restart
[ https://issues.apache.org/jira/browse/SOLR-16622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya resolved SOLR-16622. - Fix Version/s: 9.1.1 Resolution: Fixed FYI [~magibney] > Replicas don't come up active after node restart > > > Key: SOLR-16622 > URL: https://issues.apache.org/jira/browse/SOLR-16622 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 9.1.1 > > > While benchmarking for performance, we saw a sharp change in the graphs: > https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725 > Turns out there was a commit (SOLR-16414) that escaped all testing and caused > a regression where restarted nodes didn't have the replicas coming up as > active. > This affects 9.1 release, so opening a new JIRA issue to track it. -- 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-16622) Replicas don't come up active after node restart
[ https://issues.apache.org/jira/browse/SOLR-16622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677740#comment-17677740 ] ASF subversion and git services commented on SOLR-16622: Commit deb9e2439957dd42c349fc7fe2529d9fb63bd54d in solr's branch refs/heads/branch_9_1 from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=solr.git;h=deb9e243995 ] SOLR-16622, SOLR-16414: simplified code / bugfix for a node restart not working correctly > Replicas don't come up active after node restart > > > Key: SOLR-16622 > URL: https://issues.apache.org/jira/browse/SOLR-16622 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > > While benchmarking for performance, we saw a sharp change in the graphs: > https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725 > Turns out there was a commit (SOLR-16414) that escaped all testing and caused > a regression where restarted nodes didn't have the replicas coming up as > active. > This affects 9.1 release, so opening a new JIRA issue to track it. -- 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-16414) Race condition in PRS state updates
[ https://issues.apache.org/jira/browse/SOLR-16414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677741#comment-17677741 ] ASF subversion and git services commented on SOLR-16414: Commit deb9e2439957dd42c349fc7fe2529d9fb63bd54d in solr's branch refs/heads/branch_9_1 from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=solr.git;h=deb9e243995 ] SOLR-16622, SOLR-16414: simplified code / bugfix for a node restart not working correctly > Race condition in PRS state updates > --- > > Key: SOLR-16414 > URL: https://issues.apache.org/jira/browse/SOLR-16414 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Fix For: 9.1 > > Time Spent: 40m > Remaining Estimate: 0h > > For PRS collections the individual states are potentially updated from > individual nodes and sometimes from overseer too. it's possible that > > # OP1 is sent to overseer at T1 > # OP2 is executed in the node itself at T2 > > Because we cannot guarantee that the OP1 sent to overseer may execute before > OP2 tyhe final state will be the result of OP1 which is incorrect and can > lead to errors . > The solution is to never do any PRS writes from overseer. -- 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] [Created] (SOLR-16622) Replicas don't come up active after node restart
Ishan Chattopadhyaya created SOLR-16622: --- Summary: Replicas don't come up active after node restart Key: SOLR-16622 URL: https://issues.apache.org/jira/browse/SOLR-16622 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Ishan Chattopadhyaya While benchmarking for performance, we saw a sharp change in the graphs: https://issues.apache.org/jira/browse/SOLR-16525?focusedCommentId=17676725=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17676725 Turns out there was a commit (SOLR-16414) that escaped all testing and caused a regression where restarted nodes didn't have the replicas coming up as active. This affects 9.1 release, so opening a new JIRA issue to track it. -- 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] janhoy commented on pull request #1295: Use $scope.isPermitted("my-permissiong") in security dash
janhoy commented on PR #1295: URL: https://github.com/apache/solr/pull/1295#issuecomment-1385290310 I also found that `security.js` redefined the global `$scope.permissions` also defined in `app.js` which holds a static map of all permission names. I renamed the variable to `$scope.permissionsConfig` to avoid this, although I cannot really find any direct use in html angular directives, so I think it caused no bugs. wdyt? -- 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] janhoy opened a new pull request, #1295: Use $scope.isPermitted("my-permissiong") in security dash
janhoy opened a new pull request, #1295: URL: https://github.com/apache/solr/pull/1295 Re-using this global function, we can simplify the js code of the dashboard. Note that the backend `/admin/info/system` already returns an array of user's permissions, not roles. During testing I found that the app.js `isPermitted()` function did not support the `all` permission, so that's why I added that as well. This can probably be folded in with #1294, but I wanted to separate it for clarity first. The `roleMatch()` function that I patched in that PR is still in use one other place in `security.js`, in the `onPermFilterOptionChanged()` function. Not sure if we can get rid of that too here? -- 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] janhoy commented on pull request #1294: SOLR-16621: Admin UI fails to grant user permissions with wildcard role
janhoy commented on PR #1294: URL: https://github.com/apache/solr/pull/1294#issuecomment-1385173003 @thelabdude I see some duplicate logic in the permission check for Security Dash. I believe you could have used the function `isPermitted()` already defined in `app.js`, see https://github.com/apache/solr/blob/main/solr/webapp/web/js/angular/app.js#L528-L533 ? -- 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] janhoy opened a new pull request, #1294: SOLR-16621: Admin UI fails to grant user permissions with wildcard role
janhoy opened a new pull request, #1294: URL: https://github.com/apache/solr/pull/1294 https://issues.apache.org/jira/browse/SOLR-16621 Always grant access to a permission that has has the wildcard `"*"` role, no matter what roles user has. Note, this is not the same as not requiring authentication for the permission, `"roles": null`. It means that the permission needs an authenticated user, but any role will do. Also, this is just UI stuff so will not modify actual permissions on the API level, but will align role checking logic so it matches that of the backend. To test: 1. Start Solr and enable security ```bash ./gradlew dev cd solr/packaging/build/dev/ bin/solr start -c bin/solr auth enable -credentials solr:solr -blockUnknown true ``` 2. Log in to Admin UI with 'solr' and 'solr': http://localhost:8983/solr/#/~security 3. Edit the permissions 'security-edit' and 'security-read' to have `*` as role 4. The user can still see the Security Dashboard and edit permissions (To confirm the bug, do the same test on main branch and see that user is blocked from security dashboard once the permissions are changed to `role=*`). -- 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] [Created] (SOLR-16621) Admin UI fails to grant user permissions that have wildcard role
Jan Høydahl created SOLR-16621:
--
Summary: Admin UI fails to grant user permissions that have
wildcard role
Key: SOLR-16621
URL: https://issues.apache.org/jira/browse/SOLR-16621
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Security UI
Affects Versions: 9.1
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Admin UI has a Security Dashboard that requires the 'security-read' permission
to view and the 'security-edit' permission to modify.
It will display an error message if the user lacks these permission, based on a
match of user's roles and the permission roles. This works fine.
However, if any authenticated user is granted a permission through wildcard
role, e.g.
{code:java}
"permissions": [ {"name": "security-read", "role": "*"}] {code}
...then the check fails since it does not understand wildcard roles.
[~thelabdude]
--
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
