[GitHub] [lucene-solr] ErickErickson commented on a change in pull request #1535: SOLR-14474: Fix remaining auxilliary class warnings in Solr
ErickErickson commented on a change in pull request #1535: URL: https://github.com/apache/lucene-solr/pull/1535#discussion_r429692516 ## File path: solr/core/src/java/org/apache/solr/search/facet/FacetParser.java ## @@ -16,18 +16,22 @@ */ package org.apache.solr.search.facet; +import java.util.List; +import java.util.ArrayList; +import java.util.Map; +import java.util.Optional; + import org.apache.solr.common.SolrException; import org.apache.solr.common.params.SolrParams; import org.apache.solr.common.util.NamedList; import org.apache.solr.common.util.StrUtils; +import org.apache.solr.search.FunctionQParser; Review comment: Haven't the faintest clue whether it was the IDE or me reconciling the imports 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1535: SOLR-14474: Fix remaining auxilliary class warnings in Solr
dsmiley commented on a change in pull request #1535:
URL: https://github.com/apache/lucene-solr/pull/1535#discussion_r429689783
##
File path: solr/core/src/java/org/apache/solr/search/facet/FacetParser.java
##
@@ -16,18 +16,22 @@
*/
package org.apache.solr.search.facet;
+import java.util.List;
+import java.util.ArrayList;
+import java.util.Map;
+import java.util.Optional;
+
import org.apache.solr.common.SolrException;
import org.apache.solr.common.params.SolrParams;
import org.apache.solr.common.util.NamedList;
import org.apache.solr.common.util.StrUtils;
+import org.apache.solr.search.FunctionQParser;
Review comment:
Strange; I wonder why you (your IDE) re-ordered FunctionQParser to a
different spot that is no longer alphabetic? I don't care much about this so
you can leave it but it's curious.
##
File path: solr/core/src/java/org/apache/solr/search/facet/FacetParser.java
##
@@ -134,9 +138,9 @@ public Object parseFacetOrStat(String key, String type,
Object args) throws Synt
switch (type) {
case "field":
case "terms":
-return new FacetRequest.FacetFieldParser(this, key).parse(args);
+return new FacetFieldParser(this, key).parse(args);
Review comment:
Nice; seeing this simple difference makes it clear to me we're now
organizing it correctly.
##
File path:
solr/core/src/java/org/apache/solr/search/join/GraphEdgeCollector.java
##
@@ -74,8 +74,10 @@ public void setCollectDocs(FixedBitSet target) {
}
// the number of docs visited
- public int getNumHits() { return numHits; }
-
+ public int getNumHits() {
Review comment:
I admit, I'm a fan of simple one-liners like how it was :-)
##
File path: solr/core/src/java/org/apache/solr/update/TransactionLog.java
##
@@ -222,7 +222,8 @@ public boolean writePrimitive(Object val) throws
IOException {
}
// for subclasses
- protected TransactionLog() {}
+ protected TransactionLog() {
Review comment:
I guess I failed to convince you :-)
##
File path:
solr/core/src/java/org/apache/solr/search/join/GraphEdgeCollector.java
##
@@ -115,87 +117,90 @@ public void doSetNextReader(LeafReaderContext context)
throws IOException {
public ScoreMode scoreMode() {
return ScoreMode.COMPLETE_NO_SCORES;
}
-
-}
-class GraphTermsCollector extends GraphEdgeCollector {
- // all the collected terms
- private BytesRefHash collectorTerms;
- private SortedSetDocValues docTermOrds;
+ static class GraphTermsCollector extends GraphEdgeCollector {
+// all the collected terms
+private BytesRefHash collectorTerms;
+private SortedSetDocValues docTermOrds;
- GraphTermsCollector(SchemaField collectField, DocSet skipSet, DocSet
leafNodes) {
-super(collectField, skipSet, leafNodes);
-this.collectorTerms = new BytesRefHash();
- }
- @Override
- public void doSetNextReader(LeafReaderContext context) throws IOException {
-super.doSetNextReader(context);
-// Grab the updated doc values.
-docTermOrds = DocValues.getSortedSet(context.reader(),
collectField.getName());
- }
+GraphTermsCollector(SchemaField collectField, DocSet skipSet, DocSet
leafNodes) {
+ super(collectField, skipSet, leafNodes);
+ this.collectorTerms = new BytesRefHash();
+}
- @Override
- void addEdgeIdsToResult(int doc) throws IOException {
-// set the doc to pull the edges ids for.
-if (doc > docTermOrds.docID()) {
- docTermOrds.advance(doc);
+@Override
+public void doSetNextReader(LeafReaderContext context) throws IOException {
+ super.doSetNextReader(context);
+ // Grab the updated doc values.
+ docTermOrds = DocValues.getSortedSet(context.reader(),
collectField.getName());
}
-if (doc == docTermOrds.docID()) {
- BytesRef edgeValue = new BytesRef();
- long ord;
- while ((ord = docTermOrds.nextOrd()) != SortedSetDocValues.NO_MORE_ORDS)
{
-edgeValue = docTermOrds.lookupOrd(ord);
-// add the edge id to the collector terms.
-collectorTerms.add(edgeValue);
+
+@Override
+void addEdgeIdsToResult(int doc) throws IOException {
+ // set the doc to pull the edges ids for.
+ if (doc > docTermOrds.docID()) {
+docTermOrds.advance(doc);
+ }
+ if (doc == docTermOrds.docID()) {
+BytesRef edgeValue = new BytesRef();
+long ord;
+while ((ord = docTermOrds.nextOrd()) !=
SortedSetDocValues.NO_MORE_ORDS) {
+ edgeValue = docTermOrds.lookupOrd(ord);
+ // add the edge id to the collector terms.
+ collectorTerms.add(edgeValue);
+}
}
}
- }
- @Override
- public Query getResultQuery(SchemaField matchField, boolean useAutomaton) {
-if (collectorTerms == null || collectorTerms.size() == 0) {
- // return null if there are no terms (edges) to traverse.
- return null;
-} else {
- //
[jira] [Commented] (SOLR-14474) Fix remaining auxilliary class warnings in Solr
[ https://issues.apache.org/jira/browse/SOLR-14474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115599#comment-17115599 ] Erick Erickson commented on SOLR-14474: --- New PR up, incorporates David's comments. Thanks! > Fix remaining auxilliary class warnings in Solr > --- > > Key: SOLR-14474 > URL: https://issues.apache.org/jira/browse/SOLR-14474 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > We have quite a number of situations where multiple classes are declared in a > single source file, which is a poor practice. I ran across a bunch of these > in solr/core, and [~mdrob] fixed some of these in SOLR-14426. [~dsmiley] > looked at those and thought that it would have been better to just move a > particular class to its own file. And [~uschindler] do you have any comments? > I have a fork with a _bunch_ of changes to get warnings out that include > moving more than a few classes into static inner classes, including the one > Mike did. I do NOT intend to commit this, it's too big/sprawling, but it does > serve to show a variety of situations. See: > https://github.com/ErickErickson/lucene-solr/tree/jira/SOLR-10810 for how > ugly it all looks. I intend to break this wodge down into smaller tasks and > start over now that I have a clue as to the scope. And do ignore the generics > changes as well as the consequences of upgrading apache commons CLI, those > need to be their own JIRA. > What I'd like to do is agree on some guidelines for when to move classes to > their own file and when to move them to static inner classes. > Some things I saw, reference the fork for the changes (again, I won't check > that in). > 1> DocValuesAcc has no fewer than 9 classes that could be moved inside the > main class. But they all become "static abstract". And take > "DoubleSortedNumericDVAcc" in that class, It gets extended over in 4 other > files. How would all that get resolved? How many of them would people > recommend moving into their own files? Do we want to proliferate all those? > And so on with all the other plethora of classes in > org.apache.solr.search.facet. > This is particularly thorny because the choices would be about a zillion new > classes or about a zillion edits. > Does the idea of abstract .vs. concrete classes make any difference? IOW, if > we change an abstract class to a nested class, then maybe we just have to > change the class(es) that extend it? > 2> StatsComponent.StatsInfo probably should be its own file? > 3> FloatCmp, LongCmp, DoubleCmp all declare classes with "Comp" rather than > "Cmp". Those files should just be renamed. > 4> JSONResponseWriter. ??? > 5> FacetRangeProcessor seems like it needs its own class > 6> FacetRequestSorted seems like it needs its own class > 7> FacetModule > So what I'd like going forward is to agree on some guidelines to resolve > whether to move a class to its own file or make it nested (probably static). > Not hard-and-fast rules, just something to cut down on the rework due to > objections. > And what about backporting to 8x? My suggestion is to backport what's > easy/doesn't break back-compat in order to make keeping the two branches in > sync. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson opened a new pull request #1535: SOLR-14474: Fix remaining auxilliary class warnings in Solr
ErickErickson opened a new pull request #1535: URL: https://github.com/apache/lucene-solr/pull/1535 Version 2, incorporating D. Smiley's comments, thanks! 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9378) Configurable compression for BinaryDocValues
[
https://issues.apache.org/jira/browse/LUCENE-9378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115553#comment-17115553
]
Michael McCandless commented on LUCENE-9378:
{quote}As an alternative to API changes and on/off stuff (which is costly, it
means supporting multiple formats), maybe the compression should be less
aggressive, similar to what was implemented for the terms dictionary?
{quote}
+1, if we can find that compromise. Stored fields offers {{BEST}} and
{{FAST}}; maybe we can find the same balanced options here?
> Configurable compression for BinaryDocValues
>
>
> Key: LUCENE-9378
> URL: https://issues.apache.org/jira/browse/LUCENE-9378
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Viral Gandhi
>Priority: Minor
>
> Lucene 8.5.1 includes a change to always [compress
> BinaryDocValues|https://issues.apache.org/jira/browse/LUCENE-9211]. This
> caused (~30%) reduction in our red-line QPS (throughput).
> We think users should be given some way to opt-in for this compression
> feature instead of always being enabled which can have a substantial query
> time cost as we saw during our upgrade. [~mikemccand] suggested one possible
> approach by introducing a *mode* in Lucene80DocValuesFormat (COMPRESSED and
> UNCOMPRESSED) and allowing users to create a custom Codec subclassing the
> default Codec and pick the format they want.
> Idea is similar to Lucene50StoredFieldsFormat which has two modes,
> Mode.BEST_SPEED and Mode.BEST_COMPRESSION.
> Here's related issues for adding benchmark covering BINARY doc values
> query-time performance - [https://github.com/mikemccand/luceneutil/issues/61]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson commented on pull request #1533: SOLR-14474
ErickErickson commented on pull request #1533: URL: https://github.com/apache/lucene-solr/pull/1533#issuecomment-633235060 > Thanks for doing this! > > There are subclasses of FacetParser that are located as inner classes within FacetRequest. I think they should be moved to be inner classes of FacetParser. WDYT? The point is logical organization. Yeah, good catch. I've been concentrating on getting the warnings out and, especially when it comes to this kind of organization miss some of the higher-level considerations, which is one reason I'm glad for your review. Anyway, another PR coming later today. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson closed pull request #1533: SOLR-14474
ErickErickson closed pull request #1533: URL: https://github.com/apache/lucene-solr/pull/1533 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson commented on a change in pull request #1533: SOLR-14474
ErickErickson commented on a change in pull request #1533:
URL: https://github.com/apache/lucene-solr/pull/1533#discussion_r429638118
##
File path:
solr/core/src/java/org/apache/solr/handler/component/StatsComponent.java
##
@@ -167,89 +167,91 @@ public void finishStage(ResponseBuilder rb) {
public String getDescription() {
return "Calculate Statistics";
}
-}
-/**
- * Models all of the information about stats needed for a single request
- * @see StatsField
- */
-class StatsInfo {
-
- private final ResponseBuilder rb;
- private final List statsFields = new ArrayList<>(7);
- private final Map distribStatsValues = new
LinkedHashMap<>();
- private final Map statsFieldMap = new LinkedHashMap<>();
- private final Map> tagToStatsFields = new
LinkedHashMap<>();
-
- public StatsInfo(ResponseBuilder rb) {
-this.rb = rb;
-SolrParams params = rb.req.getParams();
-String[] statsParams = params.getParams(StatsParams.STATS_FIELD);
-if (null == statsParams) {
- // no stats.field params, nothing to parse.
- return;
-}
-
-for (String paramValue : statsParams) {
- StatsField current = new StatsField(rb, paramValue);
- statsFields.add(current);
- for (String tag : current.getTagList()) {
-List fieldList = tagToStatsFields.get(tag);
-if (fieldList == null) {
- fieldList = new ArrayList<>();
+
+ /**
+ * Models all of the information about stats needed for a single request
+ *
+ * @see StatsField
+ */
+ static class StatsInfo {
Review comment:
Yeah, lost track of that, thanks for pointing it out! It'll be in the
next PR.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson commented on a change in pull request #1533: SOLR-14474
ErickErickson commented on a change in pull request #1533:
URL: https://github.com/apache/lucene-solr/pull/1533#discussion_r429630097
##
File path: solr/core/src/java/org/apache/solr/update/TransactionLog.java
##
@@ -657,7 +659,8 @@ public LogReader(long startingPos) {
}
// for classes that extend
-protected LogReader() {}
Review comment:
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson commented on a change in pull request #1533: SOLR-14474
ErickErickson commented on a change in pull request #1533:
URL: https://github.com/apache/lucene-solr/pull/1533#discussion_r429629302
##
File path: solr/core/src/java/org/apache/solr/cloud/OverseerElectionContext.java
##
@@ -0,0 +1,109 @@
+/*
+ * 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.cloud;
+
+import java.lang.invoke.MethodHandles;
+import org.apache.solr.common.SolrException;
+import org.apache.solr.common.SolrException.ErrorCode;
+import org.apache.solr.common.cloud.SolrZkClient;
+import org.apache.solr.common.cloud.ZkCmdExecutor;
+import org.apache.solr.common.cloud.ZkNodeProps;
+import org.apache.solr.common.util.Utils;
+import org.apache.zookeeper.CreateMode;
+import org.apache.zookeeper.KeeperException;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import static org.apache.solr.common.params.CommonParams.ID;
+final class OverseerElectionContext extends ElectionContext {
Review comment:
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14504) ZkController LiveNodesListener has NullPointerException in startup race
[
https://issues.apache.org/jira/browse/SOLR-14504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115157#comment-17115157
]
ASF subversion and git services commented on SOLR-14504:
Commit 57703a11cfc41ca74744549e1f08713772fb5b02 in lucene-solr's branch
refs/heads/branch_8x from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=57703a1 ]
SOLR-14504: ZkController LiveNodesListener has NullPointerException in startup
race.
> ZkController LiveNodesListener has NullPointerException in startup race
> ---
>
> Key: SOLR-14504
> URL: https://issues.apache.org/jira/browse/SOLR-14504
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3,
> 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14504.patch
>
>
> If a NODELOST event happens before the cloudManager is initialized then a
> NullPointerException will occur on this line
> [https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
> {code:java}
> byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
> cloudManager.getTimeSource().getEpochTimeNs())); {code}
> Rather than accessing cloudManager directly, getSolrCloudManager() should be
> called.
>
> This happens very rarely, but if it happens it will stop Solr starting,
> result in "CoreContainer is either not initialized or shutting down". Snippet
> from 8.3.1
> {noformat}
> 2020-05-19 03:44:40.241 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.245 INFO (zkConnectionManagerCallback-11-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.245 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.359 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.361 INFO (zkConnectionManagerCallback-13-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.361 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.417 INFO (main) [ ] o.a.s.c.c.ZkStateReader Updated
> live nodes from ZooKeeper... (0) -> (1)
> 2020-05-19
> 03:44:56.606 INFO (zkCallback-12-thread-2) [ ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) ->
> (0)
> 2020-05-19 03:44:56.614 ERROR (main) [ ]
> o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
> property and the logs
> 2020-05-19 03:44:56.639 ERROR (main) [ ] o.a.s.c.SolrCore
> null:java.lang.NullPointerException
> at
> org.apache.solr.cloud.ZkController.lambda$registerLiveNodesListener$10(ZkController.java:1020)
> at
> org.apache.solr.common.cloud.ZkStateReader.registerLiveNodesListener(ZkStateReader.java:880)
> at
> org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)
> at org.apache.solr.cloud.ZkController.init(ZkController.java:917)
> at org.apache.solr.cloud.ZkController.(ZkController.java:473)
> at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:115)
> at
> org.apache.solr.core.CoreContainer.load(CoreContainer.java:631){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14280) SolrConfig logging not helpful
[
https://issues.apache.org/jira/browse/SOLR-14280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-14280:
--
Attachment: getmessages.txt
Status: Patch Available (was: Patch Available)
It'd be trivial to add a check for mentioning getMessage or getCause (or any
other string/pattern for that matter) to the Gradle logging call validation.
I've attached the results of one run, < 90 such calls were flagged against
current master.
It'd be a separate JIRA, but this could be an optional check or a mandatory
one. If the latter, someone needs to volunteer to address them all. I'd be
happy to make the change to the logging validation check and provide any
coaching in using it. I suspect it'd never actually be used if optional, so I'd
prefer mandatory.
NOTE: there's already a mechanism (adding //logok to the log line) to suppress
the validation checks for an individual logging line as necessary, so we could
leave those calls in where appropriate even if the check is not optional. And
it'd also remove some of the if (log.is###Enabled) clauses.
The way logging validation works from inside IntelliJ means that navigating to
anything that is reported by logging validation is just clicking on the error
message (other IDEs IDK) so it's not as painful as trying to go from the
attached report.
If someone wants to volunteer, make a JIRA for adding this check to logging
validation, assign it to me (or @mention me in the text) and I'll make the
check happen.
> SolrConfig logging not helpful
> --
>
> Key: SOLR-14280
> URL: https://issues.apache.org/jira/browse/SOLR-14280
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andras Salamon
>Priority: Minor
> Attachments: SOLR-14280-01.patch, SOLR-14280-02.patch, getmessages.txt
>
>
> SolrConfig prints out a warning message if it's not able to add files to the
> classpath, but this message is not too helpful:
> {noformat}
> o.a.s.c.SolrConfig Couldn't add files from
> /opt/cloudera/parcels/CDH-7.1.1-1.cdh7.1.1.p0.1850855/lib/solr/dist filtered
> by solr-langid-\d.*\.jar to classpath:
> /opt/cloudera/parcels/CDH-7.1.1-1.cdh7.1.1.p0.1850855/lib/solr/
> dist {noformat}
> The reason should be at the end of the log message but it's just repeats the
> problematic file name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14347) Autoscaling placement wrong when concurrent replica placements are calculated
[
https://issues.apache.org/jira/browse/SOLR-14347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115075#comment-17115075
]
Ilan Ginzburg commented on SOLR-14347:
--
[~ab] I am blocked due to the issue reported above of Session reuse not working
and placement being unbalanced.
Are you working on this or should I give it a try?
> Autoscaling placement wrong when concurrent replica placements are calculated
> -
>
> Key: SOLR-14347
> URL: https://issues.apache.org/jira/browse/SOLR-14347
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Affects Versions: 8.5
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Critical
> Fix For: 8.6
>
> Attachments: SOLR-14347.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Steps to reproduce:
> * create a cluster of a few nodes (tested with 7 nodes)
> * define per-collection policies that distribute replicas exclusively on
> different nodes per policy
> * concurrently create a few collections, each using a different policy
> * resulting replica placement will be seriously wrong, causing many policy
> violations
> Running the same scenario but instead creating collections sequentially
> results in no violations.
> I suspect this is caused by incorrect locking level for all collection
> operations (as defined in {{CollectionParams.CollectionAction}}) that create
> new replica placements - i.e. CREATE, ADDREPLICA, MOVEREPLICA, DELETENODE,
> REPLACENODE, SPLITSHARD, RESTORE, REINDEXCOLLECTION. All of these operations
> use the policy engine to create new replica placements, and as a result they
> change the cluster state. However, currently these operations are locked (in
> {{OverseerCollectionMessageHandler.lockTask}} ) using
> {{LockLevel.COLLECTION}}. In practice this means that the lock is held only
> for the particular collection that is being modified.
> A straightforward fix for this issue is to change the locking level to
> CLUSTER (and I confirm this fixes the scenario described above). However,
> this effectively serializes all collection operations listed above, which
> will result in general slow-down of all collection operations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14469) Removed deprecated code in solr/core (master only)
[
https://issues.apache.org/jira/browse/SOLR-14469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115034#comment-17115034
]
David Smiley commented on SOLR-14469:
-
I'd prefer we do nothing more than what we're already doing -- leave the
{{-Xlint:-deprecation}} in {{defaults-java.gradle}}. I think it's a nice "best
practice" for our deprecations to have helpful info on what to do. I'm just
unsure of the value of trying to automate this best practice to insist on it.
> Removed deprecated code in solr/core (master only)
> --
>
> Key: SOLR-14469
> URL: https://issues.apache.org/jira/browse/SOLR-14469
> Project: Solr
> Issue Type: Sub-task
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> I'm currently working on getting all the warnings out of the code, so this is
> something of a placeholder for a week or two.
> There will be sub-tasks, please create them when you start working on a
> project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
