[GitHub] [lucene-solr] trdillon opened a new pull request #2193: SOLR-15025: MiniSolrCloudCluster.waitForAllNodes ignores passed timeout value
trdillon opened a new pull request #2193: URL: https://github.com/apache/lucene-solr/pull/2193 # Description `MiniSolrCloudCluster.waitForAllNodes` ignores passed timeout value and creates a `TimeOut` with 30 seconds. # Solution Pass the provided timeout value to the `TimeOut` # Tests ./gradlew check # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [x] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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] dweiss merged pull request #2190: Make :localSettings always available, even if it's a noop on subsequent runs
dweiss merged pull request #2190: URL: https://github.com/apache/lucene-solr/pull/2190 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] madrob commented on a change in pull request #2187: SOLR-15052 Reducing overseer bottlenecks using per-replica states (8x)
madrob commented on a change in pull request #2187:
URL: https://github.com/apache/lucene-solr/pull/2187#discussion_r554164613
##
File path: solr/core/src/java/org/apache/solr/cloud/ZkController.java
##
@@ -64,31 +64,8 @@
import org.apache.solr.common.AlreadyClosedException;
import org.apache.solr.common.SolrException;
import org.apache.solr.common.SolrException.ErrorCode;
-import org.apache.solr.common.cloud.BeforeReconnect;
-import org.apache.solr.common.cloud.ClusterState;
-import org.apache.solr.common.cloud.ConnectionManager;
-import org.apache.solr.common.cloud.DefaultConnectionStrategy;
-import org.apache.solr.common.cloud.DefaultZkACLProvider;
-import org.apache.solr.common.cloud.DefaultZkCredentialsProvider;
-import org.apache.solr.common.cloud.DocCollection;
-import org.apache.solr.common.cloud.DocCollectionWatcher;
-import org.apache.solr.common.cloud.LiveNodesListener;
-import org.apache.solr.common.cloud.NodesSysPropsCacher;
-import org.apache.solr.common.cloud.OnReconnect;
-import org.apache.solr.common.cloud.Replica;
+import org.apache.solr.common.cloud.*;
Review comment:
please don't do wildcard imports.
##
File path: solr/core/src/java/org/apache/solr/cloud/overseer/NodeMutator.java
##
@@ -76,7 +80,12 @@
}
if (needToUpdateCollection) {
Review comment:
we no longer need this boolean, can check whether downedReplicas is
empty or not to decide
##
File path: solr/core/src/java/org/apache/solr/cloud/ZkController.java
##
@@ -1609,12 +1586,40 @@ public void publish(final CoreDescriptor cd, final
Replica.State state, boolean
if (updateLastState) {
cd.getCloudDescriptor().setLastPublished(state);
}
- overseerJobQueue.offer(Utils.toJSON(m));
+ DocCollection coll = zkStateReader.getCollection(collection);
+ if (forcePublish || sendToOverseer(coll, coreNodeName)) {
Review comment:
other places we do additional checks, like
https://github.com/apache/lucene-solr/pull/2187/files#diff-5307cc9f51d88f5a171591d2f429779e22b0168cd2114275d745bccea9d1a6b3R186
please be consistent about whether we care to optimize for early termination
(I suspect we don't)
##
File path:
solr/core/src/test/org/apache/solr/handler/TestStressThreadBackup.java
##
@@ -61,7 +60,7 @@
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
-@Nightly
+//@Nightly
Review comment:
?
##
File path: solr/solrj/src/java/org/apache/solr/common/cloud/Replica.java
##
@@ -129,11 +143,23 @@ public Replica(String name, Map propMap,
String collection, Strin
Objects.requireNonNull(this.nodeName, "'node_name' must not be null");
Objects.requireNonNull(this.core, "'core' must not be null");
Objects.requireNonNull(this.type, "'type' must not be null");
-if (propMap.get(ZkStateReader.STATE_PROP) != null) {
- this.state = State.getState((String)
propMap.get(ZkStateReader.STATE_PROP));
+ClusterState.getReplicaStatesProvider().get().ifPresent(it -> {
+ log.debug("A replica {} state fetched from per-replica state", name);
Review comment:
nit: I think this would be confusing, people might think it means that
the state fetched was "A" for Active. Would log "Replica..."
##
File path: solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java
##
@@ -1576,14 +1614,24 @@ public static DocCollection
getCollectionLive(ZkStateReader zkStateReader, Strin
}
}
- private DocCollection fetchCollectionState(String coll, Watcher watcher)
throws KeeperException, InterruptedException {
-String collectionPath = getCollectionPath(coll);
+ public DocCollection fetchCollectionState(String coll, Watcher watcher,
String path) throws KeeperException, InterruptedException {
+String collectionPath = path == null ? getCollectionPath(coll) : path;
while (true) {
+ ClusterState.initReplicaStateProvider(() -> {
+try {
+ PerReplicaStates replicaStates =
PerReplicaStates.fetch(collectionPath, zkClient, null);
+ log.info("per-replica-state ver: {} fetched for initializing {} ",
replicaStates.cversion, collectionPath);
+ return replicaStates;
+} catch (Exception e) {
+ //TODO
Review comment:
?
##
File path:
solr/solrj/src/java/org/apache/solr/common/cloud/PerReplicaStatesOps.java
##
@@ -0,0 +1,301 @@
+/*
+ * 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
[GitHub] [lucene-solr] slackhappy commented on pull request #2189: SOLR-14413 fix unit test to use delayed handler
slackhappy commented on pull request #2189: URL: https://github.com/apache/lucene-solr/pull/2189#issuecomment-756956274 thanks for making these changes, certainly an improvement! 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] thelabdude commented on a change in pull request #2132: SOLR-15036: auto- select / rollup / sort / plist over facet expression when using a collection alias with multiple collec
thelabdude commented on a change in pull request #2132:
URL: https://github.com/apache/lucene-solr/pull/2132#discussion_r554052572
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/DrillStream.java
##
@@ -252,29 +253,27 @@ public void setStreamContext(StreamContext streamContext)
{
}
protected void constructStreams() throws IOException {
-
try {
-
Object pushStream = ((Expressible)
tupleStream).toExpression(streamFactory);
-
- List shardUrls = getShards(this.zkHost, this.collection,
this.streamContext);
-
- for(int w=0; w {
Review comment:
This refactor makes use of the enhancement provided by SOLR-14987 to
reuse HttpSolrClients per host vs. one per replica
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/FacetStream.java
##
@@ -20,15 +20,19 @@
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
+import java.util.HashMap;
Review comment:
This source file did not adhere to the community code format so I
reformatted it. It's bad practice in general, but since my PR was getting
dinged for format issues, I chose to fix globally in this file vs. piecemeal.
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/FacetStream.java
##
@@ -537,14 +555,29 @@ public void setStreamContext(StreamContext context) {
}
public void open() throws IOException {
-if(cache != null) {
+if (cache != null) {
cloudSolrClient = cache.getCloudSolrClient(zkHost);
} else {
final List hosts = new ArrayList<>();
hosts.add(zkHost);
cloudSolrClient = new Builder(hosts,
Optional.empty()).withSocketTimeout(3).withConnectionTimeout(15000).build();
}
+// Parallelize the facet expression across multiple collections for an
alias using plist if possible
+if (params.getBool("plist", defaultPlistEnabled)) {
Review comment:
this is the main hook to see if the auto-plist approach should apply to
this facet expression
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/FacetStream.java
##
@@ -842,10 +881,99 @@ public int getCost() {
@Override
public StreamComparator getStreamSort() {
-if(bucketSorts.length > 1) {
- return new MultipleFieldComparator(bucketSorts);
+return (bucketSorts.length > 1) ? new MultipleFieldComparator(bucketSorts)
: bucketSorts[0];
+ }
+
+ @Override
Review comment:
Implementation of the `ParallelMetricsRollup` interface starts here ...
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/metrics/MaxMetric.java
##
@@ -86,7 +86,7 @@ public void update(Tuple tuple) {
if(l > longMax) {
longMax = l;
}
-} else {
+} else if(o instanceof Long) {
Review comment:
the current format is consistent with the rest of the source file, best
not to mix formatting even if it's wrong
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] gerlowskija edited a comment on pull request #2183: SOLR-15070: Remove HashMap usage in SuggestComponent rsp
gerlowskija edited a comment on pull request #2183:
URL: https://github.com/apache/lucene-solr/pull/2183#issuecomment-756877504
> If the client side doesn't change, then does that mean this is safe to
back port to 8x?
Sorry, I think a comment I made above was misleading. This PR as a whole
will change the deserialized NamedList response structures that SolrJ users get
back. Which makes this approach tough to backport as-is. I do intend to
commit a branch_8x fix to workaround the ClassCastException on the client side,
but that'll be a different approach.
My comment above that starts "This changes the object used on the server
side [only] ..." was intended to address in advance a question I thought you
might ask following the switch to SimpleOrderedMap. ("Hey I still see the
`NamedList` type in QueryResponse, why didn't the Suggest code change there as
well?"). But in hindsight I see why that comment reads like I'm saying this is
backwards-compatible. Sorry for the confusion.
To your other question, I might have interest in looking into ClusterInfo.
But if so, I'll probably punt it to a separate PR so that I can wait for
feedback on a [mailing list
thread](http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3CCAPCX2-%2BuGBgagBWPeD8wT%3Dud9p3_cbWxW77vH1RPZqaNVpZXGA%40mail.gmail.com%3E)
that relates to all this (without holding up the Suggest code 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.
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] HoustonPutman commented on pull request #2191: Add gradle settings for github actions.
HoustonPutman commented on pull request #2191: URL: https://github.com/apache/lucene-solr/pull/2191#issuecomment-757042563 Not sure why it cause docker tests to fail, but oh well. Works fine for the SolrJ and Gradle Precommit. 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] gerlowskija commented on pull request #2183: SOLR-15070: Remove HashMap usage in SuggestComponent rsp
gerlowskija commented on pull request #2183:
URL: https://github.com/apache/lucene-solr/pull/2183#issuecomment-756877504
> If the client side doesn't change, then does that mean this is safe to
back port to 8x?
Sorry, I think a comment I made above was misleading. This PR as a whole
will change the deserialized NamedList response structures that SolrJ users get
back. Which makes this approach tough to backport as-is.
My comment above that starts "This changes the object used on the server
side [only] ..." was intended to address in advance a question I thought you
might ask following the switch to SimpleOrderedMap. ("Hey I still see the
`NamedList` type in QueryResponse, why didn't the Suggest code change there as
well?"). But in hindsight I see why that comment reads like I'm saying this is
backwards-compatible. Sorry for the confusion.
To your other question, I might have interest in looking into ClusterInfo.
But if so, I'll probably punt it to a separate PR so that I can wait for
feedback on a [mailing list
thread](http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3CCAPCX2-%2BuGBgagBWPeD8wT%3Dud9p3_cbWxW77vH1RPZqaNVpZXGA%40mail.gmail.com%3E)
that relates to all this (without holding up the Suggest code 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.
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] tflobbe merged pull request #2174: Remove unused test file
tflobbe merged pull request #2174: URL: https://github.com/apache/lucene-solr/pull/2174 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] HoustonPutman merged pull request #2089: SOLR-14999: Option to set the advertised port for Solr.
HoustonPutman merged pull request #2089: URL: https://github.com/apache/lucene-solr/pull/2089 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] noblepaul commented on a change in pull request #2187: SOLR-15052 Reducing overseer bottlenecks using per-replica states (8x)
noblepaul commented on a change in pull request #2187:
URL: https://github.com/apache/lucene-solr/pull/2187#discussion_r554294274
##
File path:
solr/solrj/src/java/org/apache/solr/common/cloud/PerReplicaStates.java
##
@@ -0,0 +1,310 @@
+/*
+ * 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.common.cloud;
+
+import java.io.IOException;
+import java.lang.invoke.MethodHandles;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.LinkedHashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.Objects;
+import java.util.Set;
+import java.util.function.BiConsumer;
+
+import org.apache.solr.cluster.api.SimpleMap;
+import org.apache.solr.common.MapWriter;
+import org.apache.solr.common.SolrException;
+import org.apache.solr.common.annotation.JsonProperty;
+import org.apache.solr.common.util.ReflectMapWriter;
+import org.apache.solr.common.util.StrUtils;
+import org.apache.solr.common.util.WrappedSimpleMap;
+import org.apache.zookeeper.KeeperException;
+import org.apache.zookeeper.data.Stat;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import static org.apache.solr.common.params.CommonParams.NAME;
+import static org.apache.solr.common.params.CommonParams.VERSION;
+
+/**
+ * This represents the individual replica states in a collection
+ * This is an immutable object. When states are modified, a new instance is
constructed
+ */
+public class PerReplicaStates implements ReflectMapWriter {
+ private static final Logger log =
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
+ public static final char SEPARATOR = ':';
+ //no:of times to retry in case of a CAS failure
+ public static final int MAX_RETRIES = 5;
+
+
+ @JsonProperty
+ public final String path;
+
+ @JsonProperty
+ public final int cversion;
+
+ @JsonProperty
+ public final SimpleMap states;
+
+ /**
+ * Construct with data read from ZK
+ * @param path path from where this is loaded
+ * @param cversion the current child version of the znode
+ * @param states the per-replica states (the list of all child nodes)
+ */
+ public PerReplicaStates(String path, int cversion, List states) {
+this.path = path;
+this.cversion = cversion;
+Map tmp = new LinkedHashMap<>();
+
+for (String state : states) {
+ State rs = State.parse(state);
+ if (rs == null) continue;
+ State existing = tmp.get(rs.replica);
+ if (existing == null) {
+tmp.put(rs.replica, rs);
+ } else {
+tmp.put(rs.replica, rs.insert(existing));
+ }
+}
+this.states = new WrappedSimpleMap<>(tmp);
+
+ }
+
+ /**Get the changed replicas
+ */
+ public static Set findModifiedReplicas(PerReplicaStates old,
PerReplicaStates fresh) {
+Set result = new HashSet<>();
+if (fresh == null) {
+ old.states.forEachKey(result::add);
+ return result;
+}
+old.states.forEachEntry((s, state) -> {
+ // the state is modified or missing
+ if (!Objects.equals(fresh.get(s) , state)) result.add(s);
+});
+fresh.states.forEachEntry((s, state) -> { if (old.get(s) == null )
result.add(s);
+});
+return result;
+ }
+
+
+ /**
+ * Fetch the latest {@link PerReplicaStates} . It fetches data after
checking the {@link Stat#getCversion()} of state.json.
+ * If this is not modified, the same object is returned
+ */
+ public static PerReplicaStates fetch(String path, SolrZkClient zkClient,
PerReplicaStates current) {
+try {
+ if (current != null) {
+Stat stat = zkClient.exists(current.path, null, true);
+if (stat == null) return new PerReplicaStates(path, -1,
Collections.emptyList());
+if (current.cversion == stat.getCversion()) return current;// not
modifiedZkStateReaderTest
+ }
+ Stat stat = new Stat();
+ List children = zkClient.getChildren(path, null, stat, true);
+ return new PerReplicaStates(path, stat.getCversion(),
Collections.unmodifiableList(children));
+} catch (KeeperException e) {
+ throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "Error
fetching per-replica states", e);
+} catch (InterruptedException e)
[GitHub] [lucene-solr] slackhappy commented on a change in pull request #2189: SOLR-14413 fix unit test to use delayed handler
slackhappy commented on a change in pull request #2189:
URL: https://github.com/apache/lucene-solr/pull/2189#discussion_r554151852
##
File path: solr/core/src/test/org/apache/solr/CursorPagingTest.java
##
@@ -521,6 +522,7 @@ public void testTimeAllowed() throws Exception {
"fl", "id",
"sort", "id asc",
"rows", "50",
+"qt", "/delayed",
Review comment:
ah! wasn't sure how to do this, `qt`!
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] HoustonPutman merged pull request #2191: Add gradle settings for github actions.
HoustonPutman merged pull request #2191: URL: https://github.com/apache/lucene-solr/pull/2191 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 pull request #2192: SOLR-15010 Try to use jattach for threaddump if jstack is missing
dsmiley commented on pull request #2192: URL: https://github.com/apache/lucene-solr/pull/2192#issuecomment-757330086 Thanks Eric! 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] iverase merged pull request #2188: [Backport] LUCENE-9641: Support for spatial relationships in LatLonPoint (#2155)
iverase merged pull request #2188: URL: https://github.com/apache/lucene-solr/pull/2188 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] [Assigned] (LUCENE-9659) Support inequality operations in payload check queries
[ https://issues.apache.org/jira/browse/LUCENE-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gus Heck reassigned LUCENE-9659: Assignee: Gus Heck > Support inequality operations in payload check queries > -- > > Key: LUCENE-9659 > URL: https://issues.apache.org/jira/browse/LUCENE-9659 > Project: Lucene - Core > Issue Type: New Feature > Components: core/search >Reporter: Kevin Watters >Assignee: Gus Heck >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > This is a ticket broken out from > https://issues.apache.org/jira/browse/SOLR-14787 > The patch will extend the SpanPayloadCheck query to support inequality checks > to see if the term and payload should match. Currently, this query operator > only supports equals as the payload check. This ticket introduces > gt,gte,lt,lte and eq operations to support testing if a payload is greater > than/less than a specified reference payload value. One such use case is to > have a label on a document with a confidence level stored as a payload. This > patch will support searching for the term where a confidence level is above a > given threshold. > -- 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-12559) FunctionQParser.FLAG_USE_FIELDNAME_SOURCE doesn't work when subparsers are involved
[
https://issues.apache.org/jira/browse/SOLR-12559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261899#comment-17261899
]
ASF subversion and git services commented on SOLR-12559:
Commit 503c7eac53e30b252eac89d943948628d48f8555 in lucene-solr's branch
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=503c7ea ]
SOLR-12559: fix error when multi-val fields are derefernced in JSON aggs
This ensures all derefernced fields are not parsed into actual valuesource
but parsed into a placeholder value. This works for 1-level of dereferencing
> FunctionQParser.FLAG_USE_FIELDNAME_SOURCE doesn't work when subparsers are
> involved
> ---
>
> Key: SOLR-12559
> URL: https://issues.apache.org/jira/browse/SOLR-12559
> Project: Solr
> Issue Type: Bug
> Components: Facet Module
>Reporter: Chris M. Hostetter
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-12559.patch
>
>
> While working on a patch dealing with json facet syntax parsing, i was trying
> to write a test verifying the equivalence of 2 json facet requests that
> should be identical and discovered that when SOLR-10613 was implemented to
> defer the parsing of field names via {{FieldNameValueSource}} the
> implementation did not account for the invocation of sub parsers via param
> references.
> specifically -- this json facet request will produce two AggValueSources
> which are not {{equals()}}...
> {noformat}
> curl http://localhost:8983/solr/query -d 'q=*:*_field=foo_i&
> json.facet={
> x : "min(foo_i)",
> y : "min($my_field)"
> }'
> {noformat}
> "x" uses {{FieldNameValueSource}} while "y" directly uses an
> {{IntValueSource}}
> (It's not immediately obvious to me if this currently causes any user visible
> bugs or performance hicups, but it will definitely be problematic for users
> once we add support for {{min(multivalued_field_i)}} )
--
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-12559) FunctionQParser.FLAG_USE_FIELDNAME_SOURCE doesn't work when subparsers are involved
[
https://issues.apache.org/jira/browse/SOLR-12559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-12559:
Fix Version/s: 8.8
Resolution: Fixed
Status: Resolved (was: Patch Available)
> FunctionQParser.FLAG_USE_FIELDNAME_SOURCE doesn't work when subparsers are
> involved
> ---
>
> Key: SOLR-12559
> URL: https://issues.apache.org/jira/browse/SOLR-12559
> Project: Solr
> Issue Type: Bug
> Components: Facet Module
>Reporter: Chris M. Hostetter
>Assignee: Munendra S N
>Priority: Major
> Fix For: 8.8
>
> Attachments: SOLR-12559.patch
>
>
> While working on a patch dealing with json facet syntax parsing, i was trying
> to write a test verifying the equivalence of 2 json facet requests that
> should be identical and discovered that when SOLR-10613 was implemented to
> defer the parsing of field names via {{FieldNameValueSource}} the
> implementation did not account for the invocation of sub parsers via param
> references.
> specifically -- this json facet request will produce two AggValueSources
> which are not {{equals()}}...
> {noformat}
> curl http://localhost:8983/solr/query -d 'q=*:*_field=foo_i&
> json.facet={
> x : "min(foo_i)",
> y : "min($my_field)"
> }'
> {noformat}
> "x" uses {{FieldNameValueSource}} while "y" directly uses an
> {{IntValueSource}}
> (It's not immediately obvious to me if this currently causes any user visible
> bugs or performance hicups, but it will definitely be problematic for users
> once we add support for {{min(multivalued_field_i)}} )
--
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] (LUCENE-9661) Another classloader deadlock?
[
https://issues.apache.org/jira/browse/LUCENE-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261898#comment-17261898
]
Namgyu Kim commented on LUCENE-9661:
Hi Mike,
I checked this issue and there is a problem with the static initialize part of
TermsEnum class.
Deadlocks can occur if the constructor part of BaseTermsEnum is executed during
initializing of TermsEnum.
I uploaded the issue reproduction patch.
(Run testDeadlock in TestTermsEnum class)
I think fixing the issue is simple.
1) Change from "TermsEnum EMPTY = new BaseTermsEnum()" to "TermsEnum EMPTY =
new TermsEnum()" -> Commented out on my patch
2) Make EmptyTermsEnum class
However, it is difficult how to write a test for this issue.
Is there a good way?
> Another classloader deadlock?
> -
>
> Key: LUCENE-9661
> URL: https://issues.apache.org/jira/browse/LUCENE-9661
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: master (9.0)
>Reporter: Michael McCandless
>Priority: Major
> Attachments: deadlock_test.patch
>
>
> The {{java}} processes spawned by our Lucene nightly benchmarks sometimes
> randomly hang, apparently while loading classes across threads, under
> contention.
> I've opened [this {{luceneutil}} issue with some
> details|https://github.com/mikemccand/luceneutil/issues/89], but
> [~uschindler] suggested I open an issue here too since he has been seeing
> this in CI builds too.
> It is rare, maybe once a week in the nightly benchmarks (which spawn many
> {{java}} processes with many threads across 128 CPU cores). It is clearly a
> deadlock – when it strikes, the process hangs forever until I notice and
> {{kill -9}} it. I posted a coupled {{jstacks}} in the issue above.
> [~rcmuir] suggested using {{classcycle}} to maybe statically dig into
> possible deadlocks ... I have not tried that yet.
--
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] (LUCENE-9661) Another classloader deadlock?
[
https://issues.apache.org/jira/browse/LUCENE-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Namgyu Kim updated LUCENE-9661:
---
Attachment: deadlock_test.patch
> Another classloader deadlock?
> -
>
> Key: LUCENE-9661
> URL: https://issues.apache.org/jira/browse/LUCENE-9661
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: master (9.0)
>Reporter: Michael McCandless
>Priority: Major
> Attachments: deadlock_test.patch
>
>
> The {{java}} processes spawned by our Lucene nightly benchmarks sometimes
> randomly hang, apparently while loading classes across threads, under
> contention.
> I've opened [this {{luceneutil}} issue with some
> details|https://github.com/mikemccand/luceneutil/issues/89], but
> [~uschindler] suggested I open an issue here too since he has been seeing
> this in CI builds too.
> It is rare, maybe once a week in the nightly benchmarks (which spawn many
> {{java}} processes with many threads across 128 CPU cores). It is clearly a
> deadlock – when it strikes, the process hangs forever until I notice and
> {{kill -9}} it. I posted a coupled {{jstacks}} in the issue above.
> [~rcmuir] suggested using {{classcycle}} to maybe statically dig into
> possible deadlocks ... I have not tried that yet.
--
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] dsmiley commented on pull request #2192: SOLR-15010 Try to use jattach for threaddump if jstack is missing
dsmiley commented on pull request #2192: URL: https://github.com/apache/lucene-solr/pull/2192#issuecomment-757330086 Thanks Eric! 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-14999) Add built-in option to advertise Solr with a different port than Jetty listens on.
[
https://issues.apache.org/jira/browse/SOLR-14999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261886#comment-17261886
]
ASF subversion and git services commented on SOLR-14999:
Commit a305bad5a3397d95c373255ec5f474bfec5b84e6 in lucene-solr's branch
refs/heads/branch_8x from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a305bad ]
SOLR-14999: Fixing SolrXmlConfig tests for hostPort.
> Add built-in option to advertise Solr with a different port than Jetty
> listens on.
> --
>
> Key: SOLR-14999
> URL: https://issues.apache.org/jira/browse/SOLR-14999
> Project: Solr
> Issue Type: Improvement
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently the default settings in {{solr.xml}} allow the specification of one
> port, {{jetty.port}} which the bin/solr script provides from the
> {{SOLR_PORT}} environment variable. This port is used twice. Jetty uses it to
> listen for requests, and the clusterState uses the port to advertise the
> address of the Solr Node.
> In cloud environments, it's sometimes crucial to be able to listen on one
> port and advertise yourself as listening on another. This is because there is
> a proxy that listens on the advertised port, and forwards the request to the
> server which is listening to the jetty port.
> Solr already supports having a separate Jetty port and Live Nodes port
> (examples provided in the dev-list discussion linked below). I suggest that
> we add this to the default solr config so that users can use the default
> solr.xml in cloud configurations, and the solr/bin script will enable easy
> use of this feature.
> There has been [discussion on this exact
> problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
> on the dev list already.
> I propose the new system property to be used for {{hostPort}} in the
> solr.xml. I am open to changing the name, but to me it is more descriptive
> than {{hostPort}}.
> {{-Dsolr.port.advertise}} and {{SOLR_PORT_ADVERTISE}} (env var checked in
> bin/solr).
> The xml field {{}} would not be changed however, just the system
> property that is used to fill the value in the default {{solr.xml}}.
--
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-14999) Add built-in option to advertise Solr with a different port than Jetty listens on.
[
https://issues.apache.org/jira/browse/SOLR-14999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261885#comment-17261885
]
ASF subversion and git services commented on SOLR-14999:
Commit 7e94a56e815f28419da61eaee1e13b92a9652338 in lucene-solr's branch
refs/heads/master from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7e94a56 ]
SOLR-14999: Fixing SolrXmlConfig tests for hostPort.
> Add built-in option to advertise Solr with a different port than Jetty
> listens on.
> --
>
> Key: SOLR-14999
> URL: https://issues.apache.org/jira/browse/SOLR-14999
> Project: Solr
> Issue Type: Improvement
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently the default settings in {{solr.xml}} allow the specification of one
> port, {{jetty.port}} which the bin/solr script provides from the
> {{SOLR_PORT}} environment variable. This port is used twice. Jetty uses it to
> listen for requests, and the clusterState uses the port to advertise the
> address of the Solr Node.
> In cloud environments, it's sometimes crucial to be able to listen on one
> port and advertise yourself as listening on another. This is because there is
> a proxy that listens on the advertised port, and forwards the request to the
> server which is listening to the jetty port.
> Solr already supports having a separate Jetty port and Live Nodes port
> (examples provided in the dev-list discussion linked below). I suggest that
> we add this to the default solr config so that users can use the default
> solr.xml in cloud configurations, and the solr/bin script will enable easy
> use of this feature.
> There has been [discussion on this exact
> problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
> on the dev list already.
> I propose the new system property to be used for {{hostPort}} in the
> solr.xml. I am open to changing the name, but to me it is more descriptive
> than {{hostPort}}.
> {{-Dsolr.port.advertise}} and {{SOLR_PORT_ADVERTISE}} (env var checked in
> bin/solr).
> The xml field {{}} would not be changed however, just the system
> property that is used to fill the value in the default {{solr.xml}}.
--
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] [Created] (LUCENE-9662) CheckIndex should be concurrent
Michael McCandless created LUCENE-9662:
--
Summary: CheckIndex should be concurrent
Key: LUCENE-9662
URL: https://issues.apache.org/jira/browse/LUCENE-9662
Project: Lucene - Core
Issue Type: Bug
Reporter: Michael McCandless
I am watching a nightly benchmark run slowly run its {{CheckIndex}} step, using
a single core out of the 128 cores the box has.
It seems like this is an embarrassingly parallel problem, if the index has
multiple segments, and would finish much more quickly on concurrent hardware if
we did "thread per segment".
If wanted to get even further concurrency, each part of the Lucene index that
is checked is also independent, so it could be "thread per segment per part".
--
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-14999) Add built-in option to advertise Solr with a different port than Jetty listens on.
[
https://issues.apache.org/jira/browse/SOLR-14999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261882#comment-17261882
]
Houston Putman commented on SOLR-14999:
---
Thanks for finding that. I'll work on a fix.
> Add built-in option to advertise Solr with a different port than Jetty
> listens on.
> --
>
> Key: SOLR-14999
> URL: https://issues.apache.org/jira/browse/SOLR-14999
> Project: Solr
> Issue Type: Improvement
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently the default settings in {{solr.xml}} allow the specification of one
> port, {{jetty.port}} which the bin/solr script provides from the
> {{SOLR_PORT}} environment variable. This port is used twice. Jetty uses it to
> listen for requests, and the clusterState uses the port to advertise the
> address of the Solr Node.
> In cloud environments, it's sometimes crucial to be able to listen on one
> port and advertise yourself as listening on another. This is because there is
> a proxy that listens on the advertised port, and forwards the request to the
> server which is listening to the jetty port.
> Solr already supports having a separate Jetty port and Live Nodes port
> (examples provided in the dev-list discussion linked below). I suggest that
> we add this to the default solr config so that users can use the default
> solr.xml in cloud configurations, and the solr/bin script will enable easy
> use of this feature.
> There has been [discussion on this exact
> problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
> on the dev list already.
> I propose the new system property to be used for {{hostPort}} in the
> solr.xml. I am open to changing the name, but to me it is more descriptive
> than {{hostPort}}.
> {{-Dsolr.port.advertise}} and {{SOLR_PORT_ADVERTISE}} (env var checked in
> bin/solr).
> The xml field {{}} would not be changed however, just the system
> property that is used to fill the value in the default {{solr.xml}}.
--
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] [Reopened] (SOLR-14999) Add built-in option to advertise Solr with a different port than Jetty listens on.
[
https://issues.apache.org/jira/browse/SOLR-14999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N reopened SOLR-14999:
-
> Add built-in option to advertise Solr with a different port than Jetty
> listens on.
> --
>
> Key: SOLR-14999
> URL: https://issues.apache.org/jira/browse/SOLR-14999
> Project: Solr
> Issue Type: Improvement
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently the default settings in {{solr.xml}} allow the specification of one
> port, {{jetty.port}} which the bin/solr script provides from the
> {{SOLR_PORT}} environment variable. This port is used twice. Jetty uses it to
> listen for requests, and the clusterState uses the port to advertise the
> address of the Solr Node.
> In cloud environments, it's sometimes crucial to be able to listen on one
> port and advertise yourself as listening on another. This is because there is
> a proxy that listens on the advertised port, and forwards the request to the
> server which is listening to the jetty port.
> Solr already supports having a separate Jetty port and Live Nodes port
> (examples provided in the dev-list discussion linked below). I suggest that
> we add this to the default solr config so that users can use the default
> solr.xml in cloud configurations, and the solr/bin script will enable easy
> use of this feature.
> There has been [discussion on this exact
> problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
> on the dev list already.
> I propose the new system property to be used for {{hostPort}} in the
> solr.xml. I am open to changing the name, but to me it is more descriptive
> than {{hostPort}}.
> {{-Dsolr.port.advertise}} and {{SOLR_PORT_ADVERTISE}} (env var checked in
> bin/solr).
> The xml field {{}} would not be changed however, just the system
> property that is used to fill the value in the default {{solr.xml}}.
--
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-14999) Add built-in option to advertise Solr with a different port than Jetty listens on.
[
https://issues.apache.org/jira/browse/SOLR-14999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261880#comment-17261880
]
Munendra S N commented on SOLR-14999:
-
This has caused reproducible test failures(w/o any seed in both master and
branch_8x).
https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.x/1343/ - 2
tests are failing in TestSolrXml
> Add built-in option to advertise Solr with a different port than Jetty
> listens on.
> --
>
> Key: SOLR-14999
> URL: https://issues.apache.org/jira/browse/SOLR-14999
> Project: Solr
> Issue Type: Improvement
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently the default settings in {{solr.xml}} allow the specification of one
> port, {{jetty.port}} which the bin/solr script provides from the
> {{SOLR_PORT}} environment variable. This port is used twice. Jetty uses it to
> listen for requests, and the clusterState uses the port to advertise the
> address of the Solr Node.
> In cloud environments, it's sometimes crucial to be able to listen on one
> port and advertise yourself as listening on another. This is because there is
> a proxy that listens on the advertised port, and forwards the request to the
> server which is listening to the jetty port.
> Solr already supports having a separate Jetty port and Live Nodes port
> (examples provided in the dev-list discussion linked below). I suggest that
> we add this to the default solr config so that users can use the default
> solr.xml in cloud configurations, and the solr/bin script will enable easy
> use of this feature.
> There has been [discussion on this exact
> problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
> on the dev list already.
> I propose the new system property to be used for {{hostPort}} in the
> solr.xml. I am open to changing the name, but to me it is more descriptive
> than {{hostPort}}.
> {{-Dsolr.port.advertise}} and {{SOLR_PORT_ADVERTISE}} (env var checked in
> bin/solr).
> The xml field {{}} would not be changed however, just the system
> property that is used to fill the value in the default {{solr.xml}}.
--
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-12559) FunctionQParser.FLAG_USE_FIELDNAME_SOURCE doesn't work when subparsers are involved
[
https://issues.apache.org/jira/browse/SOLR-12559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261876#comment-17261876
]
ASF subversion and git services commented on SOLR-12559:
Commit 2c1ec75eaaa6ed60d633459667df74943ae5dd59 in lucene-solr's branch
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2c1ec75 ]
SOLR-12559: fix error when multi-val fields are derefernced in JSON aggs
This ensures all derefernced fields are not parsed into actual valuesource
but parsed into a placeholder value. This works for 1-level of dereferencing
> FunctionQParser.FLAG_USE_FIELDNAME_SOURCE doesn't work when subparsers are
> involved
> ---
>
> Key: SOLR-12559
> URL: https://issues.apache.org/jira/browse/SOLR-12559
> Project: Solr
> Issue Type: Bug
> Components: Facet Module
>Reporter: Chris M. Hostetter
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-12559.patch
>
>
> While working on a patch dealing with json facet syntax parsing, i was trying
> to write a test verifying the equivalence of 2 json facet requests that
> should be identical and discovered that when SOLR-10613 was implemented to
> defer the parsing of field names via {{FieldNameValueSource}} the
> implementation did not account for the invocation of sub parsers via param
> references.
> specifically -- this json facet request will produce two AggValueSources
> which are not {{equals()}}...
> {noformat}
> curl http://localhost:8983/solr/query -d 'q=*:*_field=foo_i&
> json.facet={
> x : "min(foo_i)",
> y : "min($my_field)"
> }'
> {noformat}
> "x" uses {{FieldNameValueSource}} while "y" directly uses an
> {{IntValueSource}}
> (It's not immediately obvious to me if this currently causes any user visible
> bugs or performance hicups, but it will definitely be problematic for users
> once we add support for {{min(multivalued_field_i)}} )
--
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] [Created] (LUCENE-9661) Another classloader deadlock?
Michael McCandless created LUCENE-9661:
--
Summary: Another classloader deadlock?
Key: LUCENE-9661
URL: https://issues.apache.org/jira/browse/LUCENE-9661
Project: Lucene - Core
Issue Type: Bug
Affects Versions: master (9.0)
Reporter: Michael McCandless
The {{java}} processes spawned by our Lucene nightly benchmarks sometimes
randomly hang, apparently while loading classes across threads, under
contention.
I've opened [this {{luceneutil}} issue with some
details|https://github.com/mikemccand/luceneutil/issues/89], but [~uschindler]
suggested I open an issue here too since he has been seeing this in CI builds
too.
It is rare, maybe once a week in the nightly benchmarks (which spawn many
{{java}} processes with many threads across 128 CPU cores). It is clearly a
deadlock – when it strikes, the process hangs forever until I notice and {{kill
-9}} it. I posted a coupled {{jstacks}} in the issue above.
[~rcmuir] suggested using {{classcycle}} to maybe statically dig into possible
deadlocks ... I have not tried that yet.
--
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] [Resolved] (SOLR-14950) schema api sometimes fails to replace-field-type
[
https://issues.apache.org/jira/browse/SOLR-14950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N resolved SOLR-14950.
-
Resolution: Fixed
> schema api sometimes fails to replace-field-type
>
>
> Key: SOLR-14950
> URL: https://issues.apache.org/jira/browse/SOLR-14950
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Affects Versions: 8.4.1
>Reporter: Andrew Shumway
>Assignee: Munendra S N
>Priority: Minor
> Labels: schema
> Fix For: 8.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When updating a schema via POST to {{/solr/COLLECTION/schema}} using
> {{replace-field-type}} , the call fails if the schema has existing
> copy-fields whose destination references a non-dynamic field of the
> {{field-type}} which is being updated.
>
> Example steps: # on a blank schema, add a field type and copy-field by POSTing
> {
> "add-field-type": [
> {
> "name": "spellcheck", "class": "solr.TextField","positionIncrementGap":
> "100",
> "analyzer": {
> "tokenizer": {
> "class": "solr.StandardTokenizerFactory"
> }
> }
> }
> ],
> "add-field": [
> {
> "name": "spellcheck", "type": "spellcheck",
> "multiValued": true, "indexed": true, "stored": true
> }
> ],
> "add-copy-field": [
> {
> "source": "important_data_s",
> "dest": "spellcheck"
> }
> ]
> }
> 2. Later, send an update for the field type
> {
> "replace-field-type": [
> {
> "name": "spellcheck", "class": "solr.TextField","positionIncrementGap":
> "100",
> "analyzer": {
> "tokenizer": {
> "class": "solr.StandardTokenizerFactory"
> }
> }
> }
> ]
> }
> This results in {{"errorMessages":["Source or Destination SchemaField can't
> be NULL.\n"]}],}}The error does not trigger if, as mentioned above, the
> destination of the existing copy-field is dynamic OR if the source field
> mapping contains a wildcard e.g. {{*foo_s}} (edited)
--
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] [Assigned] (SOLR-15010) Missing jstack warning is alarming, when using bin/solr as client interface to solr
[
https://issues.apache.org/jira/browse/SOLR-15010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Eric Pugh reassigned SOLR-15010:
--
Assignee: David Eric Pugh
> Missing jstack warning is alarming, when using bin/solr as client interface
> to solr
> ---
>
> Key: SOLR-15010
> URL: https://issues.apache.org/jira/browse/SOLR-15010
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.7
>Reporter: David Eric Pugh
>Assignee: David Eric Pugh
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In SOLR-14442 we added a warning if jstack wasn't found. I notice that I
> use the bin/solr command a lot as a client, so bin solr zk or bin solr
> healthcheck.
> For example:
> {{docker exec solr1 solr zk cp /security.json zk:security.json -z zoo1:2181}}
> All of these emit the message:
> The currently defined JAVA_HOME (/usr/local/openjdk-11) refers to a location
> where java was found but jstack was not found. Continuing.
> This is somewhat alarming, and then becomes annoying. Thoughts on maybe
> only conducting this check if you are running {{bin/solr start}} or one of
> the other commands that is actually starting Solr as a process?
--
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
