Re: [PR] Build: report test history via GE [solr]
iamsanjay commented on PR #2487: URL: https://github.com/apache/solr/pull/2487#issuecomment-2138627916 +1 Knowing test history would empower (old/**new**) Devs to make better decision. For instance, I observed that lots of build failed due to the flaky test cases, and I did not even knew about this URL before David shared it with me. Research on this: As per one survey participants were asked what information or tools would be most helpful to them in order to better handle flaky test cases, from University of Passau, ([Martin and Gordon, 2022](https://arxiv.org/abs/2203.00483)). > We observe a significant demand for improved visualization of flakiness. They specifically request tools to display test result histories, with comments such as, "We run tests so often, I often miss the bigger picture", and a desire for "a tool to visualize how tests fail and succeed over time" Additionally, they emphasize that such a tool should include meta-information like "on which device/environment [the test was executed] The second most commonly stated wish asks for tools that can automatically detect flaky test. And that's I proposed before as well and you have told me to share it on dev mailing list. I will do it! https://arxiv.org/abs/2203.00483 -- 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
Re: [PR] SOLR-16093: Tests: don't require IPv6 [solr]
dsmiley commented on PR #2484: URL: https://github.com/apache/solr/pull/2484#issuecomment-2138550449 One failing test; [reported it](https://issues.apache.org/jira/browse/SOLR-16654?focusedCommentId=17850547=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17850547) as it's a recurring failure. I'll merge this in a couple days if I get no further feedback. -- 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-16654) Add support for node-level caches
[
https://issues.apache.org/jira/browse/SOLR-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850547#comment-17850547
]
David Smiley commented on SOLR-16654:
-
[~magibney] the test has been failing about 0.5% of the time since when this
was committed:
[http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.search.TestThinCache.testSimple]
(we can't re-open this because it shipped but can just post a JIRA-less PR)
> Add support for node-level caches
> -
>
> Key: SOLR-16654
> URL: https://issues.apache.org/jira/browse/SOLR-16654
> Project: Solr
> Issue Type: New Feature
>Affects Versions: main (10.0)
>Reporter: Michael Gibney
>Priority: Minor
> Fix For: 9.4
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> Caches are currently configured only at the level of individual cores, sized
> according to expected usage patterns for the core.
> The main tradeoff in cache sizing is heap space, which is of course limited
> at the JVM/node level. Thus there is a conflict between sizing cache to
> per-core use patterns vs. sizing cache to enforce limits on overall heap
> usage.
> This issue proposes some minor changes to facilitate the introduction of
> node-level caches:
> # support a {{}} node in {{solr.xml}}, to parse named cache configs,
> for caches to be instantiated/accessible at the level of {{CoreContainer}}.
> The syntax of this config node would be identical to the syntax of the "user
> caches" config in {{solrconfig.xml}}.
> # provide a hook in searcher warming to initialize core-level caches with the
> initial associated searcher. (analogous to {{warm()}}, but for the initial
> searcher -- see SOLR-16017, which fwiw was initially opened to support a
> different use case that requires identical functionality).
> Part of the appeal of this approach is that the above (minimal) changes are
> the only changes required to enable pluggable node-level cache
> implementations -- i.e. no further API changes are necessary, and no
> behavioral changes are introduced for existing code.
> Note: I anticipate that the functionality enabled by nodel-level caches will
> mainly be useful for enforcing global resource limits -- it is not primarily
> expected to be used for sharing entries across different cores/searchers
> (although such use would be possible).
> Initial use cases envisioned:
> # "thin" core-level caches (filterCache, queryResultCache, etc.) backed by
> "node-level" caches.
> # dynamic (i.e. not static-"firstSeacher") warming of OrdinalMaps, by
> placing OrdinalMaps in an actual cache with, e.g., a time-based expiration
> policy.
> This functionality would be particularly useful for cases with many cores per
> node, and even more so in cases with uneven core usage patterns. But having
> the ability to configure resource limits at a level that directly corresponds
> to the available resources (i.e., node-level) would be generally useful for
> all cases.
--
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
[PR] Build: report test history via GE [solr]
dsmiley opened a new pull request, #2487: URL: https://github.com/apache/solr/pull/2487 Put a convenient link to test history, powered by Gradle Enterprise. Could be enhanced to also include fucit.org Improve the corresponding build logic to be more "groovy", as it's said. Example, with me forcing some failures to demo: ``` > Task :solr:core:test FAILED ERROR: The following test(s) have failed: - org.apache.solr.search.TestThinCache.testInitCore (:solr:core) Test history: https://ge.apache.org/scans/tests?search.rootProjectNames=solr-root=org.apache.solr.search.TestThinCache=testInitCore Test output: /Users/dsmiley/SFDCDev/solr_main/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.search.TestThinCache.txt Reproduce with: gradlew :solr:core:test --tests "org.apache.solr.search.TestThinCache.testInitCore" -Ptests.jvms=8 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m" -Ptests.seed=4701215A96003B03 -Ptests.useSecurityManager=false -Ptests.locale=cs-CZ -Ptests.timezone=America/Dawson_Creek -Ptests.badapples=false -Ptests.file.encoding=UTF-8 ``` Indentation should be the same as it was; just added a URL. Note that gradle.buildFinished is deprecated but [it doesn't yet have a concise replacement](https://docs.google.com/document/d/1nS1JTwdCMQN_0WaaFrSUxoQOj3zOqmKmXxC6k0OXUR0/edit#heading=h.4691loc5bp0p) so I'm leaving it be. -- 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] [Closed] (SOLR-17068) Migrate Ref Guide content to using bin/solr post command
[ https://issues.apache.org/jira/browse/SOLR-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman closed SOLR-17068. - > Migrate Ref Guide content to using bin/solr post command > > > Key: SOLR-17068 > URL: https://issues.apache.org/jira/browse/SOLR-17068 > Project: Solr > Issue Type: Sub-task > Components: documentation >Affects Versions: 9.4 >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Minor > Fix For: 9.5 > > Time Spent: 1h > Remaining Estimate: 0h > > The Ref Guide has many references to the old bin/post command (and it's > sibling awkward windows version) while ALSO having bin/solr post commands. > We need to finish the migration to bin/solr post so we don't have a awkward > split of both approaches. -- 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] [Closed] (SOLR-17128) Upgrade to Lucene 9.9.2
[ https://issues.apache.org/jira/browse/SOLR-17128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman closed SOLR-17128. - > Upgrade to Lucene 9.9.2 > --- > > Key: SOLR-17128 > URL: https://issues.apache.org/jira/browse/SOLR-17128 > Project: Solr > Issue Type: Improvement >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Blocker > Fix For: 9.5 > > > We should upgrade to the latest stable Lucene version before proceeding with > the Solr 9.5 release. Work has started on a Lucene 9.9.2 - so waiting for > that to finish releasing and then upgrading in Solr seems like our best bet. -- 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-17128) Upgrade to Lucene 9.9.2
[ https://issues.apache.org/jira/browse/SOLR-17128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-17128: -- Fix Version/s: 9.5 (was: 9.5.0) > Upgrade to Lucene 9.9.2 > --- > > Key: SOLR-17128 > URL: https://issues.apache.org/jira/browse/SOLR-17128 > Project: Solr > Issue Type: Improvement >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Blocker > Fix For: 9.5 > > > We should upgrade to the latest stable Lucene version before proceeding with > the Solr 9.5 release. Work has started on a Lucene 9.9.2 - so waiting for > that to finish releasing and then upgrading in Solr seems like our best bet. -- 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-17124) Complete Major changes and Upgrade Notes in RefGuide for 9.5.0
[ https://issues.apache.org/jira/browse/SOLR-17124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-17124: -- Fix Version/s: 9.5 (was: 9.5.0) > Complete Major changes and Upgrade Notes in RefGuide for 9.5.0 > -- > > Key: SOLR-17124 > URL: https://issues.apache.org/jira/browse/SOLR-17124 > Project: Solr > Issue Type: Improvement >Affects Versions: 9.5.0 >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Blocker > Fix For: 9.5 > > > Created as-per the instructions in the release wizard, this blocker ticket is > created to ensure that the "Major Changes" and "Upgrade Notes" sections of > our ref-guide are completed for 9.5.0 *before we announce the release*. > (It's not intended to block the RC itself or voting process.) -- 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-17068) Migrate Ref Guide content to using bin/solr post command
[ https://issues.apache.org/jira/browse/SOLR-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-17068: -- Fix Version/s: 9.5 (was: 9.5.0) > Migrate Ref Guide content to using bin/solr post command > > > Key: SOLR-17068 > URL: https://issues.apache.org/jira/browse/SOLR-17068 > Project: Solr > Issue Type: Sub-task > Components: documentation >Affects Versions: 9.4 >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Minor > Fix For: 9.5 > > Time Spent: 1h > Remaining Estimate: 0h > > The Ref Guide has many references to the old bin/post command (and it's > sibling awkward windows version) while ALSO having bin/solr post commands. > We need to finish the migration to bin/solr post so we don't have a awkward > split of both approaches. -- 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] [Closed] (SOLR-17124) Complete Major changes and Upgrade Notes in RefGuide for 9.5.0
[ https://issues.apache.org/jira/browse/SOLR-17124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman closed SOLR-17124. - > Complete Major changes and Upgrade Notes in RefGuide for 9.5.0 > -- > > Key: SOLR-17124 > URL: https://issues.apache.org/jira/browse/SOLR-17124 > Project: Solr > Issue Type: Improvement >Affects Versions: 9.5.0 >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Blocker > Fix For: 9.5 > > > Created as-per the instructions in the release wizard, this blocker ticket is > created to ensure that the "Major Changes" and "Upgrade Notes" sections of > our ref-guide are completed for 9.5.0 *before we announce the release*. > (It's not intended to block the RC itself or voting process.) -- 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] [Closed] (SOLR-17097) Upgrade to Lucene 9.9.2
[ https://issues.apache.org/jira/browse/SOLR-17097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman closed SOLR-17097. - > Upgrade to Lucene 9.9.2 > --- > > Key: SOLR-17097 > URL: https://issues.apache.org/jira/browse/SOLR-17097 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Jan Høydahl >Assignee: Jason Gerlowski >Priority: Blocker > Labels: newdev > Fix For: 9.5 > > Time Spent: 3h > Remaining Estimate: 0h > > Lucene 9.9 is released, > https://lucene.apache.org/core/9_9_1/changes/Changes.html > Leaving this Jira open for (new) devs to grab. > Instructions: > https://github.com/apache/solr/blob/main/dev-docs/lucene-upgrade.md -- 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-17097) Upgrade to Lucene 9.9.2
[ https://issues.apache.org/jira/browse/SOLR-17097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-17097: -- Fix Version/s: 9.5 (was: 9.5.0) > Upgrade to Lucene 9.9.2 > --- > > Key: SOLR-17097 > URL: https://issues.apache.org/jira/browse/SOLR-17097 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Jan Høydahl >Assignee: Jason Gerlowski >Priority: Blocker > Labels: newdev > Fix For: 9.5 > > Time Spent: 3h > Remaining Estimate: 0h > > Lucene 9.9 is released, > https://lucene.apache.org/core/9_9_1/changes/Changes.html > Leaving this Jira open for (new) devs to grab. > Instructions: > https://github.com/apache/solr/blob/main/dev-docs/lucene-upgrade.md -- 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] [Closed] (SOLR-17237) JSON Writer appears to return invalid JSON when binary fields are used
[ https://issues.apache.org/jira/browse/SOLR-17237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman closed SOLR-17237. - > JSON Writer appears to return invalid JSON when binary fields are used > -- > > Key: SOLR-17237 > URL: https://issues.apache.org/jira/browse/SOLR-17237 > Project: Solr > Issue Type: Bug > Components: JSON Request API >Affects Versions: 9.5.0 >Reporter: Karl Stoney >Priority: Major > Labels: json > Fix For: 9.6 > > Attachments: Screenshot 2024-04-18 at 09.16.23.png, Screenshot > 2024-04-29 at 08.54.30.png > > > Hello, > As per the thread on the user group, we're currently looking at upgrading to > solr 9.5.0, from v8. > We have built a fresh solr 9.5.0 from scratch, and have observed that when > requesting application/json, binary fields are not quoted - thus resulting in > invalid JSON. > I found https://issues.apache.org/jira/browse/SOLR-10653, which looks very > similar, and was "fixed" in 9.5.0. > Here's an example (partial) response that you can see (truncated the actual > value though): > ``` > "PARTNER_SITES_ADVERT_STATUS":"EXPIRED", > "DATE_OF_REGISTRATION_EPOCH":1584403200, > "STOCK_ITEM_BINARY_FIELD":OikKAfqLb3JpZ2luU291cmNlQ0=, > "FUEL_CAPACITY_VALUE":59.0 > ``` -- 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-17237) JSON Writer appears to return invalid JSON when binary fields are used
[ https://issues.apache.org/jira/browse/SOLR-17237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-17237: -- Fix Version/s: 9.6 (was: 9.6.0) > JSON Writer appears to return invalid JSON when binary fields are used > -- > > Key: SOLR-17237 > URL: https://issues.apache.org/jira/browse/SOLR-17237 > Project: Solr > Issue Type: Bug > Components: JSON Request API >Affects Versions: 9.5.0 >Reporter: Karl Stoney >Priority: Major > Labels: json > Fix For: 9.6 > > Attachments: Screenshot 2024-04-18 at 09.16.23.png, Screenshot > 2024-04-29 at 08.54.30.png > > > Hello, > As per the thread on the user group, we're currently looking at upgrading to > solr 9.5.0, from v8. > We have built a fresh solr 9.5.0 from scratch, and have observed that when > requesting application/json, binary fields are not quoted - thus resulting in > invalid JSON. > I found https://issues.apache.org/jira/browse/SOLR-10653, which looks very > similar, and was "fixed" in 9.5.0. > Here's an example (partial) response that you can see (truncated the actual > value though): > ``` > "PARTNER_SITES_ADVERT_STATUS":"EXPIRED", > "DATE_OF_REGISTRATION_EPOCH":1584403200, > "STOCK_ITEM_BINARY_FIELD":OikKAfqLb3JpZ2luU291cmNlQ0=, > "FUEL_CAPACITY_VALUE":59.0 > ``` -- 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
Re: [PR] Correct command to reproduce test with a failure in classMethod [solr]
AndreyBozhko commented on PR #2483: URL: https://github.com/apache/solr/pull/2483#issuecomment-2138176733 Thanks @madrob - any particular reason why the patch from SOLR-15447 was never applied? -- 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
Re: [PR] Factor out ModifiableSolrParams.setShardAttributesToParams method [solr]
dsmiley commented on PR #1570: URL: https://github.com/apache/solr/pull/1570#issuecomment-2138171095 See https://github.com/apache/solr/pull/2486 where I move it. Would love a +1 -- 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
[PR] Move setShardAttributesToParams [solr]
dsmiley opened a new pull request, #2486: URL: https://github.com/apache/solr/pull/2486 From ModifiableSolrParams to SearchHandler. Too special-purpose to warrant any back-compat concern. Was here since 2023-06 -- 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
Re: [PR] SOLR-15164: Implement Task Management Interface [solr]
dsmiley commented on code in PR #76:
URL: https://github.com/apache/solr/pull/76#discussion_r1619409451
##
solr/core/src/java/org/apache/solr/handler/component/TaskManagementHandler.java:
##
@@ -0,0 +1,146 @@
+/*
+ * 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.handler.component;
+
+import org.apache.solr.common.SolrException;
+import org.apache.solr.common.params.CommonParams;
+import org.apache.solr.common.params.ModifiableSolrParams;
+import org.apache.solr.common.params.ShardParams;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.core.SolrCore;
+import org.apache.solr.handler.RequestHandlerBase;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+import org.apache.solr.security.PermissionNameProvider;
+import org.apache.solr.util.plugin.SolrCoreAware;
+
+import java.io.IOException;
+import java.util.ArrayList;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Map;
+
+import static org.apache.solr.common.params.CommonParams.DISTRIB;
+import static org.apache.solr.common.params.CommonParams.PATH;
+
+/**
+ * Abstract class which serves as the root of all task managing handlers
+ */
+public abstract class TaskManagementHandler extends RequestHandlerBase
implements SolrCoreAware, PermissionNameProvider {
+private ShardHandlerFactory shardHandlerFactory;
+
+@Override
+public void inform(SolrCore core) {
+this.shardHandlerFactory =
core.getCoreContainer().getShardHandlerFactory();
+}
+
+/**
+ * Process the actual request.
+ * extraParams is required for allowing sub handlers to pass in custom
parameters to be put in the
+ * outgoing shard request
+ */
+protected void processRequest(SolrQueryRequest req, ResponseBuilder rb,
Map extraParams) throws IOException {
+ShardHandler shardHandler = shardHandlerFactory.getShardHandler();
+List components = rb.components;
Review Comment:
Something similar happened once -- RealTimeGetHandler. It's really a
handler only for RealtimeGetComponent, so I might also question that design
too. But RTGH is subclassing SearchHandler, so there is _no_ duplication of
SearchHandler's complexity. If you have time, I recommend a simple change of
these handlers you added to mimick RTGH.
--
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
Re: [PR] SOLR-15164: Implement Task Management Interface [solr]
dsmiley commented on code in PR #76:
URL: https://github.com/apache/solr/pull/76#discussion_r1619398738
##
solr/core/src/java/org/apache/solr/handler/component/TaskManagementHandler.java:
##
@@ -0,0 +1,146 @@
+/*
+ * 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.handler.component;
+
+import org.apache.solr.common.SolrException;
+import org.apache.solr.common.params.CommonParams;
+import org.apache.solr.common.params.ModifiableSolrParams;
+import org.apache.solr.common.params.ShardParams;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.core.SolrCore;
+import org.apache.solr.handler.RequestHandlerBase;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+import org.apache.solr.security.PermissionNameProvider;
+import org.apache.solr.util.plugin.SolrCoreAware;
+
+import java.io.IOException;
+import java.util.ArrayList;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Map;
+
+import static org.apache.solr.common.params.CommonParams.DISTRIB;
+import static org.apache.solr.common.params.CommonParams.PATH;
+
+/**
+ * Abstract class which serves as the root of all task managing handlers
+ */
+public abstract class TaskManagementHandler extends RequestHandlerBase
implements SolrCoreAware, PermissionNameProvider {
+private ShardHandlerFactory shardHandlerFactory;
+
+@Override
+public void inform(SolrCore core) {
+this.shardHandlerFactory =
core.getCoreContainer().getShardHandlerFactory();
+}
+
+/**
+ * Process the actual request.
+ * extraParams is required for allowing sub handlers to pass in custom
parameters to be put in the
+ * outgoing shard request
+ */
+protected void processRequest(SolrQueryRequest req, ResponseBuilder rb,
Map extraParams) throws IOException {
+ShardHandler shardHandler = shardHandlerFactory.getShardHandler();
+List components = rb.components;
Review Comment:
@atris I'm commenting on this years later, I realize, but I question the
complexity in this design in using SearchComponents. SearchComponents are
designed expressly for SearchHandler; to allow many interesting features to
exist together in a search pipeline of sorts for one request. Pretty
excellent. Here, I see that the same design was used but only for one function
-- a simple requirement. It's a heavyweight solution for a simple task. If
your answer is, for distributed-processing -- that's not necessary. For
example see org.apache.solr.handler.admin.AdminHandlersProxy#maybeProxyToNodes
(granted I don't love it) or places in SolrCloud that use ShardHandler directly
(better).
--
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
Re: [PR] Correct command to reproduce test with a failure in classMethod [solr]
gus-asf commented on PR #2483: URL: https://github.com/apache/solr/pull/2483#issuecomment-2138043439 if we are touching this lets add a `./` on the front of the command so one can actually cut and paste it :) -- 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
Re: [PR] Correct command to reproduce test with a failure in classMethod [solr]
madrob commented on PR #2483: URL: https://github.com/apache/solr/pull/2483#issuecomment-2138003318 See also https://issues.apache.org/jira/browse/SOLR-15447 -- 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-17315) Bug in messaging when creating a collection, and then you can't actually call the config method to set-user-property
[
https://issues.apache.org/jira/browse/SOLR-17315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh updated SOLR-17315:
-
Summary: Bug in messaging when creating a collection, and then you can't
actually call the config method to set-user-property (was: Bug in messaging
when creating a collection)
> Bug in messaging when creating a collection, and then you can't actually call
> the config method to set-user-property
>
>
> Key: SOLR-17315
> URL: https://issues.apache.org/jira/browse/SOLR-17315
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: 9.6
>Reporter: Eric Pugh
>Priority: Minor
>
> I made a collection, and noticed the default message doesn't format properly:
>
> {{{
> bin/solr create -c stuff
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> WARN - 2024-05-29 13:48:32.981; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkCredentialsInjector. ZkCredentialsInjector is not secure, it
> creates an empty list of credentials which leads to 'OPEN_ACL_UNSAFE' ACLs to
> Zookeeper nodes
> WARN - 2024-05-29 13:48:33.049; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkACLProvider. DefaultZkACLProvider is not secure, it creates
> 'OPEN_ACL_UNSAFE' ACLs to Zookeeper nodes
> WARNING: Using _default configset. Data driven schema functionality is
> enabled by default, which is
> NOT RECOMMENDED for production use.
> To turn it off:
> curl http://localhost:8983/null/config -d '\{"set-user-property":
> {"update.autoCreateFields":"false"}}'
> Or:
> bin/solr config -c null -p 8983 -action set-user-property
> -property update.autoCreateFields -value false
> }}}
>
> -c null is wrong. Also, on main, the -p didn't work!
--
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-17315) Bug in messaging when creating a collection
[
https://issues.apache.org/jira/browse/SOLR-17315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh updated SOLR-17315:
-
Affects Version/s: 9.6
(was: main (10.0))
> Bug in messaging when creating a collection
> ---
>
> Key: SOLR-17315
> URL: https://issues.apache.org/jira/browse/SOLR-17315
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: 9.6
>Reporter: Eric Pugh
>Priority: Minor
>
> I made a collection, and noticed the default message doesn't format properly:
>
> {{{
> bin/solr create -c stuff
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> WARN - 2024-05-29 13:48:32.981; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkCredentialsInjector. ZkCredentialsInjector is not secure, it
> creates an empty list of credentials which leads to 'OPEN_ACL_UNSAFE' ACLs to
> Zookeeper nodes
> WARN - 2024-05-29 13:48:33.049; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkACLProvider. DefaultZkACLProvider is not secure, it creates
> 'OPEN_ACL_UNSAFE' ACLs to Zookeeper nodes
> WARNING: Using _default configset. Data driven schema functionality is
> enabled by default, which is
> NOT RECOMMENDED for production use.
> To turn it off:
> curl http://localhost:8983/null/config -d '\{"set-user-property":
> {"update.autoCreateFields":"false"}}'
> Or:
> bin/solr config -c null -p 8983 -action set-user-property
> -property update.autoCreateFields -value false
> }}}
>
> -c null is wrong. Also, on main, the -p didn't work!
--
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-17315) Bug in messaging when creating a collection
[
https://issues.apache.org/jira/browse/SOLR-17315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850450#comment-17850450
]
Eric Pugh commented on SOLR-17315:
--
With the default docker-compose for solr cloud from
[https://solr.apache.org/guide/solr/latest/deployment-guide/solr-in-docker.html#docker-compose]
run docker exec dev-solr-1 solr create -c stuff and then docker exec dev-solr-1
solr config -c stuff -action set-user-property -property
update.autoCreateFields -value false
> Bug in messaging when creating a collection
> ---
>
> Key: SOLR-17315
> URL: https://issues.apache.org/jira/browse/SOLR-17315
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: main (10.0)
>Reporter: Eric Pugh
>Priority: Minor
>
> I made a collection, and noticed the default message doesn't format properly:
>
> {{{
> bin/solr create -c stuff
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> WARN - 2024-05-29 13:48:32.981; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkCredentialsInjector. ZkCredentialsInjector is not secure, it
> creates an empty list of credentials which leads to 'OPEN_ACL_UNSAFE' ACLs to
> Zookeeper nodes
> WARN - 2024-05-29 13:48:33.049; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkACLProvider. DefaultZkACLProvider is not secure, it creates
> 'OPEN_ACL_UNSAFE' ACLs to Zookeeper nodes
> WARNING: Using _default configset. Data driven schema functionality is
> enabled by default, which is
> NOT RECOMMENDED for production use.
> To turn it off:
> curl http://localhost:8983/null/config -d '\{"set-user-property":
> {"update.autoCreateFields":"false"}}'
> Or:
> bin/solr config -c null -p 8983 -action set-user-property
> -property update.autoCreateFields -value false
> }}}
>
> -c null is wrong. Also, on main, the -p didn't work!
--
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-17315) Bug in messaging when creating a collection
Eric Pugh created SOLR-17315:
Summary: Bug in messaging when creating a collection
Key: SOLR-17315
URL: https://issues.apache.org/jira/browse/SOLR-17315
Project: Solr
Issue Type: Sub-task
Components: cli
Affects Versions: main (10.0)
Reporter: Eric Pugh
I made a collection, and noticed the default message doesn't format properly:
{{{
bin/solr create -c stuff
Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
http://localhost:8983.
Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
http://localhost:8983.
WARN - 2024-05-29 13:48:32.981; org.apache.solr.common.cloud.SolrZkClient;
Using default ZkCredentialsInjector. ZkCredentialsInjector is not secure, it
creates an empty list of credentials which leads to 'OPEN_ACL_UNSAFE' ACLs to
Zookeeper nodes
WARN - 2024-05-29 13:48:33.049; org.apache.solr.common.cloud.SolrZkClient;
Using default ZkACLProvider. DefaultZkACLProvider is not secure, it creates
'OPEN_ACL_UNSAFE' ACLs to Zookeeper nodes
WARNING: Using _default configset. Data driven schema functionality is enabled
by default, which is
NOT RECOMMENDED for production use.
To turn it off:
curl http://localhost:8983/null/config -d '\{"set-user-property":
{"update.autoCreateFields":"false"}}'
Or:
bin/solr config -c null -p 8983 -action set-user-property -property
update.autoCreateFields -value false
}}}
-c null is wrong. Also, on main, the -p didn't work!
--
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
Re: [PR] Correct command to reproduce test with a failure in classMethod [solr]
AndreyBozhko commented on code in PR #2483:
URL: https://github.com/apache/solr/pull/2483#discussion_r1619247178
##
gradle/testing/failed-tests-at-end.gradle:
##
@@ -25,11 +25,12 @@ allprojects {
tasks.withType(Test) { Test task ->
afterTest { desc, result ->
if (result.resultType == TestResult.ResultType.FAILURE) {
+def testOrClassName = desc.name == "classMethod" ? desc.className :
"${desc.className}.${desc.name}"
failedTests << [
"name": "${desc.className}.${desc.name}",
Review Comment:
It just happened so that in the GHA check
(https://github.com/apache/solr/actions/runs/9274510162/job/25517863554) for
this PR, a couple of tests failed - and one could see how the failures are
reported:
* lines 479-478
```
> Task :solr:modules:ltr:test
org.apache.solr.ltr.feature.TestUserTermScoreWithQ > testUserTermScoreWithQ
FAILED
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([1B9234167BEFFA61]:0)
org.apache.solr.ltr.feature.TestUserTermScoreWithQ > classMethod FAILED
java.lang.Exception: Suite timeout exceeded (>= 60 msec).
at __randomizedtesting.SeedInfo.seed([1B9234167BEFFA61]:0)
```
* line 1017
```
2> NOTE: reproduce with: gradlew test --tests
TestUserTermScoreWithQ.testUserTermScoreWithQ -Dtests.seed=1B9234167BEFFA61
-Dtests.locale=ar-BH -Dtests.timezone=WET -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
```
* line 1404
```
2> NOTE: reproduce with: gradlew test --tests TestUserTermScoreWithQ
-Dtests.seed=1B9234167BEFFA61 -Dtests.locale=ar-BH -Dtests.timezone=WET
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
```
* lines 1413-1420
```
ERROR: The following test(s) have failed:
-
org.apache.solr.ltr.feature.TestUserTermScoreWithQ.testUserTermScoreWithQ
(:solr:modules:ltr)
Test output:
/tmp/src/solr/solr/modules/ltr/build/test-results/test/outputs/OUTPUT-org.apache.solr.ltr.feature.TestUserTermScoreWithQ.txt
Reproduce with: gradlew :solr:modules:ltr:test --tests
"org.apache.solr.ltr.feature.TestUserTermScoreWithQ.testUserTermScoreWithQ"
-Ptests.jvms=96 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:+UseParallelGC
-XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
-Ptests.seed=1B9234167BEFFA61 -Ptests.timeoutSuite=60!
-Ptests.file.encoding=US-ASCII
- org.apache.solr.ltr.feature.TestUserTermScoreWithQ.classMethod
(:solr:modules:ltr)
Test output:
/tmp/src/solr/solr/modules/ltr/build/test-results/test/outputs/OUTPUT-org.apache.solr.ltr.feature.TestUserTermScoreWithQ.txt
Reproduce with: gradlew :solr:modules:ltr:test --tests
"org.apache.solr.ltr.feature.TestUserTermScoreWithQ" -Ptests.jvms=96
"-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:+UseParallelGC
-XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
-Ptests.seed=1B9234167BEFFA61 -Ptests.timeoutSuite=60!
-Ptests.file.encoding=US-ASCII
```
Note that this PR only adjusts the line 1420 from the last block, - it now
becomes consistent with line 1404 which already knew not to append
"classMethod" to the class name.
--
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
Re: [PR] Correct command to reproduce test with a failure in classMethod [solr]
HoustonPutman commented on code in PR #2483:
URL: https://github.com/apache/solr/pull/2483#discussion_r1619190342
##
gradle/testing/failed-tests-at-end.gradle:
##
@@ -25,11 +25,12 @@ allprojects {
tasks.withType(Test) { Test task ->
afterTest { desc, result ->
if (result.resultType == TestResult.ResultType.FAILURE) {
+def testOrClassName = desc.name == "classMethod" ? desc.className :
"${desc.className}.${desc.name}"
failedTests << [
"name": "${desc.className}.${desc.name}",
Review Comment:
Hmm, its still probably good to have a pretty clear indication that it was a
classMethod, right? I think it would be a bit confusing otherwise to see that
both
`org.apache.solr.ltr.feature.TestUserTermScoreWithQ.testUserTermScoreWithQ` and
`org.apache.solr.ltr.feature.TestUserTermScoreWithQ` failed
--
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] [Resolved] (SOLR-17228) Task queue stalled issues.
[ https://issues.apache.org/jira/browse/SOLR-17228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski resolved SOLR-17228. Resolution: Duplicate > Task queue stalled issues. > -- > > Key: SOLR-17228 > URL: https://issues.apache.org/jira/browse/SOLR-17228 > Project: Solr > Issue Type: Bug > Components: clients - java, http2, replication (java) >Affects Versions: 9.1.1 >Reporter: Nikolay >Priority: Blocker > > Hello Team, > We are using solr 9.1.1 in cloud mode with two replicas on two different VMs. > We are experiencing very often the following issue: > Task queue processing has stalled for 20191 ms with 0 remaining elements to > process. > I have read the similar issues but all of them are related to remaining > elements to process where in my case there are 0 remaining elements. > Could you please assist with what could cause the issue and how to solve it > please. > > java.io.IOException: Task queue processing has stalled for 20191 ms with 0 > remaining elements to process. > at > org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient.blockUntilFinished(ConcurrentUpdateHttp2SolrClient.java:508) > at > org.apache.solr.update.StreamingSolrClients.blockUntilFinished(StreamingSolrClients.java:87) > at > org.apache.solr.update.SolrCmdDistributor.blockAndDoRetries(SolrCmdDistributor.java:292) > at > org.apache.solr.update.SolrCmdDistributor.finish(SolrCmdDistributor.java:91) > at > org.apache.solr.update.processor.DistributedZkUpdateProcessor.doDistribFinish(DistributedZkUpdateProcessor.java:1263) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1253) > at > org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78) > at > org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:94) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:224) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2865) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:887) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:606) > at > org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:250) > at > org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:218) > at > org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:257) > at > org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:227) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:213) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195) > at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:201) > at > org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:191) > at > org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) > at > org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322) > at >
[jira] [Commented] (SOLR-17228) Task queue stalled issues.
[ https://issues.apache.org/jira/browse/SOLR-17228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850421#comment-17850421 ] Jason Gerlowski commented on SOLR-17228: Hi [~nikolaydocu] - this is indeed a bug. The "stall detection" currently done as a precaution by Solr's "concurrent" clients looks primarily at the the size of the queue of updates to be sent out. This often leads to false-positives both when the queue is nearly always full (e.g. during heavy indexing) and when the queue is nearly always empty (very very light indexing). We're experimenting with a fix for this in SOLR-17294 but haven't merged anything yet. We'd love some feedback on the PR in that ticket if you care to review! Since we're already tracking this work under SOLR-17294, I'm going to close this out as a duplicate. > Task queue stalled issues. > -- > > Key: SOLR-17228 > URL: https://issues.apache.org/jira/browse/SOLR-17228 > Project: Solr > Issue Type: Bug > Components: clients - java, http2, replication (java) >Affects Versions: 9.1.1 >Reporter: Nikolay >Priority: Blocker > > Hello Team, > We are using solr 9.1.1 in cloud mode with two replicas on two different VMs. > We are experiencing very often the following issue: > Task queue processing has stalled for 20191 ms with 0 remaining elements to > process. > I have read the similar issues but all of them are related to remaining > elements to process where in my case there are 0 remaining elements. > Could you please assist with what could cause the issue and how to solve it > please. > > java.io.IOException: Task queue processing has stalled for 20191 ms with 0 > remaining elements to process. > at > org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient.blockUntilFinished(ConcurrentUpdateHttp2SolrClient.java:508) > at > org.apache.solr.update.StreamingSolrClients.blockUntilFinished(StreamingSolrClients.java:87) > at > org.apache.solr.update.SolrCmdDistributor.blockAndDoRetries(SolrCmdDistributor.java:292) > at > org.apache.solr.update.SolrCmdDistributor.finish(SolrCmdDistributor.java:91) > at > org.apache.solr.update.processor.DistributedZkUpdateProcessor.doDistribFinish(DistributedZkUpdateProcessor.java:1263) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1253) > at > org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:78) > at > org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:94) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:224) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2865) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:887) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:606) > at > org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:250) > at > org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:218) > at > org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:257) > at > org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:227) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:213) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195) > at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:201) > at > org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) > at >
Re: [PR] Correct command to reproduce test with a failure in classMethod [solr]
cpoerschke commented on code in PR #2483:
URL: https://github.com/apache/solr/pull/2483#discussion_r1619145893
##
gradle/testing/failed-tests-at-end.gradle:
##
@@ -25,11 +25,12 @@ allprojects {
tasks.withType(Test) { Test task ->
afterTest { desc, result ->
if (result.resultType == TestResult.ResultType.FAILURE) {
+def testOrClassName = desc.name == "classMethod" ? desc.className :
"${desc.className}.${desc.name}"
failedTests << [
"name": "${desc.className}.${desc.name}",
Review Comment:
How about also changing this?
```suggestion
"name": "$testOrClassName",
```
(I spotted this only because in
https://github.com/apache/solr/actions/runs/9274510162/job/25517863554?pr=2483
it says _"... ERROR: The following test(s) have failed: ...
org.apache.solr.ltr.feature.TestUserTermScoreWithQ.classMethod
(:solr:modules:ltr) ..."_ currently.)
--
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-13350) Explore collector managers for multi-threaded search
[
https://issues.apache.org/jira/browse/SOLR-13350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850405#comment-17850405
]
Christine Poerschke commented on SOLR-13350:
Hello. I'd like to share some results from experiments with a subset of this
ticket's changes when benchmarking dense vector search.
Having noticed that {{AbstractKnnVectorQuery.rewrite}} has parallelism and that
Solr's {{SolrIndexSearcher}} constructor did not yet pass an executor to its
super class i.e. Lucene's {{IndexSearcher}} I was curious if picking out only
the "pass an executor" part of the changes in this ticket would be beneficial.
Links for Solr 9.4.1 using Lucene 9.8.0 version:
*
[https://github.com/apache/lucene/blob/releases/lucene/9.8.0/lucene/core/src/java/org/apache/lucene/search/AbstractKnnVectorQuery.java#L83-L87]
*
[https://github.com/apache/lucene/blob/releases/lucene/9.8.0/lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java#L235]
Links for Solr 9.5.0 using Lucene 9.9.2 version:
*
[https://github.com/apache/lucene/blob/releases/lucene/9.9.2/lucene/core/src/java/org/apache/lucene/search/AbstractKnnVectorQuery.java#L82-L88]
*
[https://github.com/apache/lucene/blob/releases/lucene/9.9.2/lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java#L233-L234]
The links are for 9.4.1 and 9.5.0 versions for convenience and to reflect
initial code reading and subsequent experimental code base.
Overall the results could be summarised as "unexpected" or "surprising" –
passing an executor increased latency by around 20x with a reduction in
container CPU use to approximately match that. The thread count used seemed to
make no difference, we've tried a few different ones.
The "just pass an executor" patch was onto a Solr 9.5 cloud, and I haven't
really dived into the details much, but I'm wondering if the implications for
this ticket here might be that searches passing {{multiThreaded=false}} could
be impacted because currently nothing controls the passing of the executor to
Lucene's {{IndexSearcher}} constructor.
(And last but not least, a shoutout to [~abenedetti] because his
[comment|https://lists.apache.org/thread/xc174z8qnls3o0by644n3fbtt28po7lc] on
[this|https://lists.apache.org/thread/0olh0z2dc78y01k34yg06yrpzts2ggmp] user
mailing list thread really encouraged me to take the time to write-up and share
these results here.)
> Explore collector managers for multi-threaded search
>
>
> Key: SOLR-13350
> URL: https://issues.apache.org/jira/browse/SOLR-13350
> Project: Solr
> Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-13350.patch, SOLR-13350.patch, SOLR-13350.patch
>
> Time Spent: 11.5h
> Remaining Estimate: 0h
>
> AFAICT, SolrIndexSearcher can be used only to search all the segments of an
> index in series. However, using CollectorManagers, segments can be searched
> concurrently and result in reduced latency. Opening this issue to explore the
> effectiveness of using CollectorManagers in SolrIndexSearcher from latency
> and throughput perspective.
--
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-17314) SolrClient implementations should not mutate request objects
Jason Gerlowski created SOLR-17314: -- Summary: SolrClient implementations should not mutate request objects Key: SOLR-17314 URL: https://issues.apache.org/jira/browse/SOLR-17314 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 9.6, main (10.0) Reporter: Jason Gerlowski Assignee: Jason Gerlowski Currently, our "load balancing" SolrClient implementations mutate the SolrRequest instances they're operating on, changing the "basePath" as a way to dictate which Solr node the request is ultimately routed to. This is effective for the LB client's purposes, but it can cause problems especially in SolrJ code that reuses SolrRequest objects for multiple requests. (This is pretty common - Solr itself and its test code does this frequently). This ticket aims to cover restructuring our "LB" client code so that it no longer quietly mutates the objects provided by callers. -- 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-17313) Remove Deprecated SolrLogPostTool
Eric Pugh created SOLR-17313: Summary: Remove Deprecated SolrLogPostTool Key: SOLR-17313 URL: https://issues.apache.org/jira/browse/SOLR-17313 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Components: cli Affects Versions: main (10.0) Reporter: Eric Pugh Assignee: Eric Pugh A follow up to SOLR-16883 is to finish removing from 10x the deprecated code. -- 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-17247) 'WWW-Authenticate' headers missing in MultiAuthPlugin
[
https://issues.apache.org/jira/browse/SOLR-17247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-17247.
--
Fix Version/s: 9.7
Resolution: Fixed
> 'WWW-Authenticate' headers missing in MultiAuthPlugin
> -
>
> Key: SOLR-17247
> URL: https://issues.apache.org/jira/browse/SOLR-17247
> Project: Solr
> Issue Type: Bug
> Components: Authentication
>Reporter: Lamine
>Assignee: Eric Pugh
>Priority: Minor
> Fix For: 9.7
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> MultiAuthPlugin does not return WWW-Authenticate' headers
> When returning a 401 response a Web application needs to indicate to the
> client what authentication challenges it supports, otherwise an exception
> like "{_}HTTP protocol violation: Authentication challenge without
> WWW-Authenticate header{_}“ is raised.
> Solr’s MultiAuthPlugin does not supports this. Solr should return the list
> of supported schemes (challenges).
>
> According to HTTP [RFC
> 7235|https://datatracker.ietf.org/doc/html/rfc7235#section-3.1]:
> _The 401 (Unauthorized) status code indicates that the request has not_
> _been applied because it lacks valid authentication credentials for_
> _the target resource. The server generating a 401 response *MUST* send_
> _a WWW-Authenticate header field ([Section
> 4.1|https://datatracker.ietf.org/doc/html/rfc7235#section-4.1]) containing at
> least one_
> _challenge applicable to the target resource._
--
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-17247) 'WWW-Authenticate' headers missing in MultiAuthPlugin
[
https://issues.apache.org/jira/browse/SOLR-17247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh reassigned SOLR-17247:
Assignee: Eric Pugh
> 'WWW-Authenticate' headers missing in MultiAuthPlugin
> -
>
> Key: SOLR-17247
> URL: https://issues.apache.org/jira/browse/SOLR-17247
> Project: Solr
> Issue Type: Bug
> Components: Authentication
>Reporter: Lamine
>Assignee: Eric Pugh
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> MultiAuthPlugin does not return WWW-Authenticate' headers
> When returning a 401 response a Web application needs to indicate to the
> client what authentication challenges it supports, otherwise an exception
> like "{_}HTTP protocol violation: Authentication challenge without
> WWW-Authenticate header{_}“ is raised.
> Solr’s MultiAuthPlugin does not supports this. Solr should return the list
> of supported schemes (challenges).
>
> According to HTTP [RFC
> 7235|https://datatracker.ietf.org/doc/html/rfc7235#section-3.1]:
> _The 401 (Unauthorized) status code indicates that the request has not_
> _been applied because it lacks valid authentication credentials for_
> _the target resource. The server generating a 401 response *MUST* send_
> _a WWW-Authenticate header field ([Section
> 4.1|https://datatracker.ietf.org/doc/html/rfc7235#section-4.1]) containing at
> least one_
> _challenge applicable to the target resource._
--
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-17247) 'WWW-Authenticate' headers missing in MultiAuthPlugin
[
https://issues.apache.org/jira/browse/SOLR-17247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850370#comment-17850370
]
ASF subversion and git services commented on SOLR-17247:
Commit 4bd265d81f9442b55d86dbb19723cde7ef04cd0f in solr's branch
refs/heads/branch_9x from Lamine
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=4bd265d81f9 ]
SOLR-17247: Fix bug - 'WWW-Authenticate' headers missing in MultiAuthPlugin
(#2416)
Co-authored-by: Lamine Idjeraoui
Co-authored-by: Eric Pugh
> 'WWW-Authenticate' headers missing in MultiAuthPlugin
> -
>
> Key: SOLR-17247
> URL: https://issues.apache.org/jira/browse/SOLR-17247
> Project: Solr
> Issue Type: Bug
> Components: Authentication
>Reporter: Lamine
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> MultiAuthPlugin does not return WWW-Authenticate' headers
> When returning a 401 response a Web application needs to indicate to the
> client what authentication challenges it supports, otherwise an exception
> like "{_}HTTP protocol violation: Authentication challenge without
> WWW-Authenticate header{_}“ is raised.
> Solr’s MultiAuthPlugin does not supports this. Solr should return the list
> of supported schemes (challenges).
>
> According to HTTP [RFC
> 7235|https://datatracker.ietf.org/doc/html/rfc7235#section-3.1]:
> _The 401 (Unauthorized) status code indicates that the request has not_
> _been applied because it lacks valid authentication credentials for_
> _the target resource. The server generating a 401 response *MUST* send_
> _a WWW-Authenticate header field ([Section
> 4.1|https://datatracker.ietf.org/doc/html/rfc7235#section-4.1]) containing at
> least one_
> _challenge applicable to the target resource._
--
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-17247) 'WWW-Authenticate' headers missing in MultiAuthPlugin
[
https://issues.apache.org/jira/browse/SOLR-17247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850369#comment-17850369
]
ASF subversion and git services commented on SOLR-17247:
Commit 14a219542bdc709bcc85b9eba2cc748caeb4ea64 in solr's branch
refs/heads/main from Lamine
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=14a219542bd ]
SOLR-17247: Fix bug - 'WWW-Authenticate' headers missing in MultiAuthPlugin
(#2416)
Co-authored-by: Lamine Idjeraoui
Co-authored-by: Eric Pugh
> 'WWW-Authenticate' headers missing in MultiAuthPlugin
> -
>
> Key: SOLR-17247
> URL: https://issues.apache.org/jira/browse/SOLR-17247
> Project: Solr
> Issue Type: Bug
> Components: Authentication
>Reporter: Lamine
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> MultiAuthPlugin does not return WWW-Authenticate' headers
> When returning a 401 response a Web application needs to indicate to the
> client what authentication challenges it supports, otherwise an exception
> like "{_}HTTP protocol violation: Authentication challenge without
> WWW-Authenticate header{_}“ is raised.
> Solr’s MultiAuthPlugin does not supports this. Solr should return the list
> of supported schemes (challenges).
>
> According to HTTP [RFC
> 7235|https://datatracker.ietf.org/doc/html/rfc7235#section-3.1]:
> _The 401 (Unauthorized) status code indicates that the request has not_
> _been applied because it lacks valid authentication credentials for_
> _the target resource. The server generating a 401 response *MUST* send_
> _a WWW-Authenticate header field ([Section
> 4.1|https://datatracker.ietf.org/doc/html/rfc7235#section-4.1]) containing at
> least one_
> _challenge applicable to the target resource._
--
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
Re: [PR] SOLR-17247: Fix bug - 'WWW-Authenticate' headers missing in MultiAuthPlugin [solr]
epugh merged PR #2416: URL: https://github.com/apache/solr/pull/2416 -- 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-17044) Improve API path specifying in SolrJ
[ https://issues.apache.org/jira/browse/SOLR-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850340#comment-17850340 ] ASF subversion and git services commented on SOLR-17044: Commit 437e27970b2ab7bbe2680e3c37d78ad410209a63 in solr's branch refs/heads/main from Jason Gerlowski [ https://gitbox.apache.org/repos/asf?p=solr.git;h=437e27970b2 ] SOLR-17044: Consolidate SolrJ URL-building logic (#2455) Prior to this commit, SolrJ had near-duplicate logic for building request paths in two different places: HttpSolrClient and HttpSolrClientBase (used by the JDK and Jetty HSC's). This commit consolidates the path-building logic for all of SolrJ, so that it can live in only one place. > Improve API path specifying in SolrJ > > > Key: SOLR-17044 > URL: https://issues.apache.org/jira/browse/SOLR-17044 > Project: Solr > Issue Type: Improvement > Components: SolrJ, v2 API >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently, URL-driven SolrClients receive a URL that typically ends in > "/solr". Requiring users to specify this context-root in their URLs has made > sense historically, since all v1 paths start with "/solr". But this has > become limiting as Solr's v2 APIs (which use the "/api" context root) become > more mature. > SolrJ has some string manipulation in a few spots to try to accomodate this, > but it's patchy and relatively brittle (relying on overly specific > 'instanceof' checks, etc.). We should come up with a more reliable way to > ensure that SolrClient's can make both v1 and v2 requests. > Here's one idea for how we could approach this: > # Create a new SolrRequest method to specify the initial path segment (i.e. > /solr vs /api) on a per-request basis. We could either do this directly > (e.g. "getRootPath()"), or indirectly (e.g. "isV2()"). > # Modify SolrClients to consider both the new method and the existing > "getPath" when sending requests. > # Add logic to SolrJ to strip "/solr" from any provided base URLs, and > document that SolrClient URLs no longer require the "/solr" context-root > suffix. -- 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
Re: [PR] SOLR-17044: Consolidate SolrJ URL-building logic [solr]
gerlowskija merged PR #2455: URL: https://github.com/apache/solr/pull/2455 -- 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
