[jira] [Created] (SOLR-17461) (cleanup) Move ClusterState string "Interner" json parser to Utils
David Smiley created SOLR-17461: --- Summary: (cleanup) Move ClusterState string "Interner" json parser to Utils Key: SOLR-17461 URL: https://issues.apache.org/jira/browse/SOLR-17461 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: David Smiley ClusterState.setStrInternerParser and its functionality is potentially of general utility and it's also a bit distracting in ClusterState. I also don't like CoreContainer being involved in initializing it (CoreContainer is doing too much!). It's doing it because ClusterState is in SolrJ without Caffeine being on the classpath. Instead, imagine a class in solr-core that implements this Function. Utils could then self-initialize via reflection detecting if that class is available, otherwise gracefully resorting to the non-intern mechanism. No touching CoreContainer which is way too busy doing many things. -- 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] Release 8.11.4 [solr-docker]
HoustonPutman opened a new pull request, #27: URL: https://github.com/apache/solr-docker/pull/27 (no comment) -- 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] Release 8.11.4 [solr-docker]
HoustonPutman merged PR #27: URL: https://github.com/apache/solr-docker/pull/27 -- 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-17459) ConfigTool does not support -scheme
[ https://issues.apache.org/jira/browse/SOLR-17459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17459. -- Fix Version/s: 9.8 Resolution: Fixed > ConfigTool does not support -scheme > --- > > Key: SOLR-17459 > URL: https://issues.apache.org/jira/browse/SOLR-17459 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: cli >Affects Versions: 9.7 >Reporter: Christos Malliaridis >Assignee: Eric Pugh >Priority: Major > Labels: cli, pull-request-available > Fix For: 9.8 > > Time Spent: 20m > Remaining Estimate: 0h > > bin/solr adds the URL scheme to the list of arguments via the -scheme flag, > but ConfigTool does not support it and throws an "unrecognized option" error. > We should add support back again and deprecate the option if it is marked for > removal. > For more details see > [https://lists.apache.org/thread/t8tnlk8sttjw8wo6q5hooglfbpk5n1vn] > See also > [https://docs.google.com/spreadsheets/d/1ws44kN51WnGwQzOXc8KKRQ93TMgHSqIGb02MRWFel_U/edit?usp=sharing] > -- 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-17158 Terminate distributed processing quickly when query limit is reached [solr]
gus-asf commented on code in PR #2666:
URL: https://github.com/apache/solr/pull/2666#discussion_r1773584764
##
solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java:
##
@@ -80,6 +94,39 @@ public HttpShardHandler(HttpShardHandlerFactory
httpShardHandlerFactory) {
shardToURLs = new HashMap<>();
}
+ /**
+ * Parse the {@value ShardParams#SHARDS_TOLERANT} param from
params as a boolean;
+ * accepts {@value ShardParams#REQUIRE_ZK_CONNECTED} as a valid value
indicating false
+ * .
+ *
+ * By default, returns false when {@value
ShardParams#SHARDS_TOLERANT} is not set
+ * in
+ * params.
+ */
+ public static boolean getShardsTolerantAsBool(SolrQueryRequest req) {
+String shardsTolerantValue =
req.getParams().get(ShardParams.SHARDS_TOLERANT);
+if (null == shardsTolerantValue
+||
shardsTolerantValue.trim().equals(ShardParams.REQUIRE_ZK_CONNECTED)) {
Review Comment:
Sorry, let me be clearer. That .trim() was retained only because it was part
of the (recent) changes for that ticket that I received in a merge from main:
(https://github.com/apache/solr/pull/2311/files) If you are confident that the
change made in SOLR-6572 was in error, we can remove it. I simply trusted the
change made by @janhoy
--
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-17378: Add a RequestHandler metric for "number of outstanding concurrent requests" [solr]
magibney commented on PR #2591: URL: https://github.com/apache/solr/pull/2591#issuecomment-2371725359 > Have you deployed it / ran it for a while to see if it behaves sensibly? Quick status update -- have _not_ yet deployed it locally. This is still definitely on the radar though, so I hope to report back and move this forward soon. -- 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-17158 Terminate distributed processing quickly when query limit is reached [solr]
gus-asf commented on code in PR #2666:
URL: https://github.com/apache/solr/pull/2666#discussion_r1773633493
##
solr/CHANGES.txt:
##
@@ -109,8 +109,11 @@ New Features
Improvements
-
+* SOLR-17158: Users for whom partial results are uninteresting may set
partialResultsAllowed=false. This allows Solr to reduce time spent processing
partial results and omit them from the response. (Gus Heck, Andrzej Bialeki,
hossman)
Review Comment:
done, chose the ascii form. Though I see some non-ascii names, I used ascii
for consistency with all your other contribs.
##
solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java:
##
@@ -80,6 +94,39 @@ public HttpShardHandler(HttpShardHandlerFactory
httpShardHandlerFactory) {
shardToURLs = new HashMap<>();
}
+ /**
+ * Parse the {@value ShardParams#SHARDS_TOLERANT} param from
params as a boolean;
+ * accepts {@value ShardParams#REQUIRE_ZK_CONNECTED} as a valid value
indicating false
+ * .
+ *
+ * By default, returns false when {@value
ShardParams#SHARDS_TOLERANT} is not set
+ * in
+ * params.
+ */
+ public static boolean getShardsTolerantAsBool(SolrQueryRequest req) {
+String shardsTolerantValue =
req.getParams().get(ShardParams.SHARDS_TOLERANT);
+if (null == shardsTolerantValue
+||
shardsTolerantValue.trim().equals(ShardParams.REQUIRE_ZK_CONNECTED)) {
+ return false;
+} else {
+ boolean tolerant = StrUtils.parseBool(shardsTolerantValue.trim());
+ if (tolerant && shouldDiscardPartials(req.getParams())) {
Review Comment:
done
##
solr/core/src/java/org/apache/solr/request/SolrRequestInfo.java:
##
@@ -66,6 +67,22 @@ public static SolrRequestInfo getRequestInfo() {
return stack.peek();
}
+ public static Optional getReqInfo() {
+return Optional.ofNullable(getRequestInfo());
+ }
+
+ public static Optional getRequest() {
+return getReqInfo().map(i -> i.req);
+ }
+
+ public static boolean shouldDiscardPartials() {
Review Comment:
removed and inlined.
--
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] Benchmark: HTTP2 fix cancel_stream_error [solr]
iamsanjay commented on PR #2612: URL: https://github.com/apache/solr/pull/2612#issuecomment-2371907560 We are using jetty 10, right? https://github.com/jetty/jetty.project/issues/10485 -- 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-17448: Audit usage of ExecutorService#submit in Solr codebase [solr]
AndreyBozhko commented on PR #2707: URL: https://github.com/apache/solr/pull/2707#issuecomment-2372354983 Hi @dsmiley, could you review this once you have time? Thanks -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. 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-14673: Add bin/solr stream CLI [solr]
epugh commented on code in PR #2479: URL: https://github.com/apache/solr/pull/2479#discussion_r1774352198 ## solr/solr-ref-guide/modules/query-guide/pages/stream-tool.adoc: ## @@ -0,0 +1,167 @@ += Stream Tool +// 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. + +The Stream tool allows you to run a xref:streaming-expressions.adoc[] and see the results from the command line. +It is very similar to the xref:stream-screen.adoc[], but is part of the `bin/solr` CLI. + +To run it, open a window and enter: + +[,console] + +$ bin/solr stream --header -c techproducts --delimiter=\| 'search(techproducts,q="name:memory",fl="name,price")' + + +This will run the provided streaming expression on the `techproducts` collection and produce: + +[,console] + +name|price +CORSAIR XMS 2GB (2 x 1GB) 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) Dual Channel Kit System Memory - Retail|185.0 +CORSAIR ValueSelect 1GB 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) System Memory - Retail|74.99 +A-DATA V-Series 1GB 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) System Memory - OEM| + + +TIP: Notice how we used the pipe character (|) as the delimiter? It required a backslash for escaping it so it wouldn't be treated as a pipe with in the shell script. + +You can also specify a file with the suffix `.expr` containing your streaming expression. +This is useful for longer expressions or if you having command line parsing issues with your expression. + +Assuming you have create the file `stream.expr` with the contents: + + +# Stream a search + +search( + techproducts, + q="name:memory", + fl="name,price", + sort="price desc" +) + + +Then you can run it on the Solr collection `techproducts`, specifying you want a header row: + +[,console] + +$ bin/solr stream --header -c techproducts stream.expr + + +And this will produce: + +[,console] + +name price +CORSAIR XMS 2GB (2 x 1GB) 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) Dual Channel Kit System Memory - Retail 185.0 +CORSAIR ValueSelect 1GB 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) System Memory - Retail 74.99 +A-DATA V-Series 1GB 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) System Memory - OEM + + +The `--help` (or simply `-h`) option will output information on its usage (i.e., `bin/solr stream --help)`. + +== Using the bin/solr stream Tool + +To use the tool you need to provide the streaming expression either inline as the last argument, or provide a file ending in `.expr` that contains the expression. + +The basic usage of `bin/solr stream` is: + +[source,plain] + +usage: bin/solr stream [--array-delimiter ] [-c ] [--delimiter ] [-f ] [--header] + [-u ] [-url ] [--workers ] [-z ] + +List of options: +--array-delimiterThe delimiter multi-valued fields. (default=|) + -c,--nameName of the collection to execute on if workers are 'solr'. Required for 'solr' +worker. +--delimiter The output delimiter. (default=tab). + -f,--fieldsThe fields in the tuples to output. (defaults to fields in the first tuple of result +set). +--headerWhether or not to include a header line. (default=false) + -u,--credentials Credentials in the format username:password. Example: --credentials solr:SolrRocks + -url,--solr-url Base Solr URL, which can be used to determine the zk-host if that's not known; +defaults to: http://localhost:8983. + -e,--executionExecution context is either 'local' or 'solr'. Default is 'solr' + -z,--zk-host Zookeeper connection string; unnecessary if ZK_HOST is defined in solr.in.sh; +otherwise, defaults to localhost:9983. + + +== Examples Using bin/solr stream + +There are several ways to use `bin/solr stream`. +This section presents several examples. + +=== Executing Expression Locally + +Streaming Expressions by default are executed in the Solr cluster. +However there are use cases where you want to interact with data in your local environm
Re: [PR] SOLR-17448: Audit usage of ExecutorService#submit in Solr codebase [solr]
dsmiley commented on code in PR #2707:
URL: https://github.com/apache/solr/pull/2707#discussion_r1774359207
##
solr/CHANGES.txt:
##
@@ -163,6 +163,8 @@ Other Changes
* SOLR-17142: Fix Gradle build sometimes gives spurious "unreferenced license
file" warnings. (Uwe Schindler)
+* SOLR-17448: Audit usage of ExecutorService#submit in Solr codebase (Andrey
Bozhko)
Review Comment:
Could you reword this into its impact instead of its technical detail? Like
maybe "fixed inadvertent suppression of exceptions across the codebase due to
...""
##
solr/core/src/java/org/apache/solr/schema/ZkIndexSchemaReader.java:
##
@@ -154,6 +151,26 @@ public void process(WatchedEvent event) {
}
}
+@Override
+public void process(WatchedEvent event) {
Review Comment:
minor: please move this method to immediately before doProcess since it
calls it.
##
solr/core/src/test/org/apache/solr/pkg/TestPackages.java:
##
@@ -810,10 +813,18 @@ public void testSchemaPlugins() throws Exception {
":fieldType:_packageinfo_:version",
"1.0"));
+JettySolrRunner jetty =
+cluster.getJettySolrRunners().stream()
+.dropWhile(j -> j.getCoreContainer().getAllCoreNames().isEmpty())
+.findFirst()
+.orElseThrow();
+
+IndexSchema schemaBeforePackageUpdate = withOnlyCoreInJetty(jetty,
SolrCore::getLatestSchema);
+
add = new PackagePayload.AddVersion();
add.version = "2.0";
add.pkg = "schemapkg";
-add.files = Arrays.asList(FILE1);
+add.files = Arrays.asList(FILE1, FILE2);
Review Comment:
Great investigation! It's a nice little story how submit() was hiding
errors!
##
solr/core/src/java/org/apache/solr/handler/admin/PrepRecoveryOp.java:
##
@@ -191,11 +195,6 @@ public void execute(CallInfo it) throws Exception {
}
}
-if (coreContainer.isShutDown()) {
Review Comment:
why remove this?
##
solr/test-framework/src/java/org/apache/solr/cloud/AbstractFullDistribZkTestBase.java:
##
@@ -1981,29 +1981,18 @@ protected void destroyServers() throws Exception {
ExecutorService customThreadPool =
ExecutorUtil.newMDCAwareCachedThreadPool(new
SolrNamedThreadFactory("closeThreadPool"));
-customThreadPool.submit(() -> IOUtils.closeQuietly(commonCloudSolrClient));
+customThreadPool.execute(() ->
IOUtils.closeQuietly(commonCloudSolrClient));
-customThreadPool.submit(() -> IOUtils.closeQuietly(controlClient));
+customThreadPool.execute(() -> IOUtils.closeQuietly(controlClient));
-customThreadPool.submit(
-() ->
-coreClients.parallelStream()
-.forEach(
-c -> {
- IOUtils.closeQuietly(c);
-}));
+customThreadPool.execute(() ->
coreClients.parallelStream().forEach(IOUtils::closeQuietly));
Review Comment:
shouldn't we avoid parallelStream? Could loop these to submit them to
customThreadPool. Same for below.
--
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-17442: Resolve -v flag conflict (version, value, verbose) [solr]
epugh commented on code in PR #2721:
URL: https://github.com/apache/solr/pull/2721#discussion_r1774359308
##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -137,6 +137,12 @@ public class SolrCLI implements CLIO {
public static final Option OPTION_SOLRURL =
Option.builder("url")
.longOpt("solr-url")
+ .deprecated(
+ DeprecatedAttributes.builder()
+ .setForRemoval(true)
+ .setSince("9.7")
+ .setDescription("Use --solr-url instead")
+ .get())
Review Comment:
interesting, I actually don't know why I added this...It doesn't seem to
fit the rest of this PR...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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-16503) Switch UpdateShardHandler.getDefaultHttpClient to Jetty HTTP2
[
https://issues.apache.org/jira/browse/SOLR-16503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884493#comment-17884493
]
David Smiley commented on SOLR-16503:
-
Sanjay is working on this one but you're welcome to review and maybe switch
over some usages of it once it's in place (will be separate PRs instead of a
mega PR; same JIRA). The latest PR introduces a CoreContainer method since
it's used so pervasively. UpdateShardHandler is a terrible home for it. He
and I discussed where it should live quite a bit; explored another option
already and settled here.
> Switch UpdateShardHandler.getDefaultHttpClient to Jetty HTTP2
> -
>
> Key: SOLR-16503
> URL: https://issues.apache.org/jira/browse/SOLR-16503
> Project: Solr
> Issue Type: Sub-task
>Reporter: David Smiley
>Priority: Major
> Labels: pull-request-available
> Attachments: Screenshot 2024-03-16 at 9.14.36 PM.png
>
> Time Spent: 9h
> Remaining Estimate: 0h
>
> Much of Solr's remaining uses of Apache HttpClient (HTTP 1) is due to
> {{org.apache.solr.update.UpdateShardHandler#getDefaultHttpClient}} which
> underlies most Solr-to-Solr connectivity. This also underlies the
> {{{}CoreContainer.getSolrClientCache{}}}. Lets switch to Jetty (HTTP 2).
>
> In SolrClientCache in particular:
> Switch use of CloudLegacySolrClient.Builder to CloudSolrClient.Builder
> Switch use of HttpSolrClient.Builder to Http2SolrClient.Builder
> Undeprecate all the methods here. They should not have been deprecated in
> the first place.
> The constructor: switch from Apache HttpClient to a Jetty HttpClient.
--
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-16503: New home for default http2 client [solr]
iamsanjay commented on code in PR #2689:
URL: https://github.com/apache/solr/pull/2689#discussion_r1774390477
##
solr/core/src/java/org/apache/solr/core/CoreContainer.java:
##
@@ -2563,6 +2581,11 @@ public PlacementPluginFactory getPlacementPlugi
return this.distributedCollectionCommandRunner;
}
+ /** Returns default http solr client. */
+ public SolrClient getDefaultHttpClient() {
Review Comment:
I got it! That is ugly. Anyways I am okay with this method returning
Http2SolrClient.
@gerlowskija I already worked on changing it for two files PKIAuth and
ReindexCollectionCmd, however we decided not to in this one and deal in
separate PR. Take a look at this one, If everything's looking good then I will
merge this one first and then I will make another.
--
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-16503: New home for default http2 client [solr]
iamsanjay commented on code in PR #2689:
URL: https://github.com/apache/solr/pull/2689#discussion_r1774390477
##
solr/core/src/java/org/apache/solr/core/CoreContainer.java:
##
@@ -2563,6 +2581,11 @@ public PlacementPluginFactory getPlacementPlugi
return this.distributedCollectionCommandRunner;
}
+ /** Returns default http solr client. */
+ public SolrClient getDefaultHttpClient() {
Review Comment:
I got it! That is ugly. Anyways I am okay with this method returning
Http2SolrClient.
@gerlowskija I already worked on changing it for two files PKIAuth and
ReindexCollectionCmd, however we decided not to include in this one and deal in
a separate PR. Take a look at this one, If everything's looking good then I
will merge this one first and then I will make another.
--
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-17457: Scavange one change from the SOLR-17457 bug fix for main [solr]
epugh merged PR #2718: URL: https://github.com/apache/solr/pull/2718 -- 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-17457) StatusTool does not support --max-wait-secs
[ https://issues.apache.org/jira/browse/SOLR-17457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884256#comment-17884256 ] ASF subversion and git services commented on SOLR-17457: Commit 6d380dbee31bc64809d2374bd0f81ccfe807a073 in solr's branch refs/heads/main from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=6d380dbee31 ] Scavange one change from the SOLR-17457 bug fix (#2718) > StatusTool does not support --max-wait-secs > --- > > Key: SOLR-17457 > URL: https://issues.apache.org/jira/browse/SOLR-17457 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCLI >Affects Versions: 9.7 >Reporter: Christos Malliaridis >Assignee: Eric Pugh >Priority: Major > Labels: cli, pull-request-available > Fix For: 9.8 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > With the changes made in SOLR-16824 the StatusTool is used by bin/solr.cmd > with --max-wait-secs, but an unrecognized option error is thrown. > See [https://lists.apache.org/thread/yjzfmh2nbg2g0wjl22sg4n97ydd42jq9] for > more details. -- 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-17459: Fix unrecognized option -scheme [solr]
epugh merged PR #2722: URL: https://github.com/apache/solr/pull/2722 -- 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] Fix bugs in bin/solr in branch_9_7 [solr]
epugh commented on code in PR #2710:
URL: https://github.com/apache/solr/pull/2710#discussion_r1773243472
##
solr/packaging/test/test_create.bats:
##
@@ -34,8 +34,31 @@ teardown() {
assert_output --partial "Created new core 'COLL_NAME'"
}
+@test "create_core works" {
+ run solr start
+ run solr create_core -c COLL_NAME
+ assert_output --partial "Created new core 'COLL_NAME'"
+}
+
@test "create for cloud mode" {
run solr start -c
run solr create -c COLL_NAME
assert_output --partial "Created collection 'COLL_NAME'"
}
+
+@test "ensure -p port parameter is supported" {
+ solr start -p ${SOLR2_PORT}
+ solr assert --not-started http://localhost:${SOLR_PORT} --timeout 5000
+ solr assert --started http://localhost:${SOLR2_PORT} --timeout 5000
+
+ run solr create -c COLL_NAME -p ${SOLR2_PORT}
+ assert_output --partial "Created new core 'COLL_NAME'"
+}
+
+@test "ensure -V verbose parameter is supported" {
+ solr start
+ solr assert --started http://localhost:${SOLR_PORT} --timeout 5000
+
+ run solr create -c COLL_NAME -V
+ assert_output --partial "Created new core 'COLL_NAME'"
Review Comment:
I finally understand what you mean, and am looking at it and then will merge.
--
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] [Assigned] (SOLR-17459) ConfigTool does not support -scheme
[ https://issues.apache.org/jira/browse/SOLR-17459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-17459: Assignee: Eric Pugh > ConfigTool does not support -scheme > --- > > Key: SOLR-17459 > URL: https://issues.apache.org/jira/browse/SOLR-17459 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: cli >Affects Versions: 9.7 >Reporter: Christos Malliaridis >Assignee: Eric Pugh >Priority: Major > Labels: cli, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > bin/solr adds the URL scheme to the list of arguments via the -scheme flag, > but ConfigTool does not support it and throws an "unrecognized option" error. > We should add support back again and deprecate the option if it is marked for > removal. > For more details see > [https://lists.apache.org/thread/t8tnlk8sttjw8wo6q5hooglfbpk5n1vn] > See also > [https://docs.google.com/spreadsheets/d/1ws44kN51WnGwQzOXc8KKRQ93TMgHSqIGb02MRWFel_U/edit?usp=sharing] > -- 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-17457: Backport fix for max-wait-secs [solr]
epugh merged PR #2719: URL: https://github.com/apache/solr/pull/2719 -- 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-17457: Backport fix for max-wait-secs [solr]
epugh commented on PR #2719: URL: https://github.com/apache/solr/pull/2719#issuecomment-2371182004 Thanks @malliaridis for the back port to `branch_9_7`. -- 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-17457) StatusTool does not support --max-wait-secs
[ https://issues.apache.org/jira/browse/SOLR-17457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884265#comment-17884265 ] ASF subversion and git services commented on SOLR-17457: Commit 9da01f58e26bb08bb01a0e77b74f5ed195be703e in solr's branch refs/heads/branch_9_7 from Christos Malliaridis [ https://gitbox.apache.org/repos/asf?p=solr.git;h=9da01f58e26 ] SOLR-17457: Backport fix for max-wait-secs (#2719) * Add support for --max-wait-secs and deprecate --maxWaitSecs in StatusTool > StatusTool does not support --max-wait-secs > --- > > Key: SOLR-17457 > URL: https://issues.apache.org/jira/browse/SOLR-17457 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCLI >Affects Versions: 9.7 >Reporter: Christos Malliaridis >Assignee: Eric Pugh >Priority: Major > Labels: cli, pull-request-available > Fix For: 9.8 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > With the changes made in SOLR-16824 the StatusTool is used by bin/solr.cmd > with --max-wait-secs, but an unrecognized option error is thrown. > See [https://lists.apache.org/thread/yjzfmh2nbg2g0wjl22sg4n97ydd42jq9] for > more details. -- 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-17459) ConfigTool does not support -scheme
Christos Malliaridis created SOLR-17459: --- Summary: ConfigTool does not support -scheme Key: SOLR-17459 URL: https://issues.apache.org/jira/browse/SOLR-17459 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: cli Affects Versions: 9.7 Reporter: Christos Malliaridis bin/solr adds the URL scheme to the list of arguments via the -scheme flag, but ConfigTool does not support it. We should add support back again and deprecate the option if it is marked for removal. For more details see https://lists.apache.org/thread/t8tnlk8sttjw8wo6q5hooglfbpk5n1vn See also [https://docs.google.com/spreadsheets/d/1ws44kN51WnGwQzOXc8KKRQ93TMgHSqIGb02MRWFel_U/edit?usp=sharing] -- 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-17459) ConfigTool does not support -scheme
[ https://issues.apache.org/jira/browse/SOLR-17459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christos Malliaridis updated SOLR-17459: Description: bin/solr adds the URL scheme to the list of arguments via the -scheme flag, but ConfigTool does not support it and throws an "unrecognized option" error. We should add support back again and deprecate the option if it is marked for removal. For more details see [https://lists.apache.org/thread/t8tnlk8sttjw8wo6q5hooglfbpk5n1vn] See also [https://docs.google.com/spreadsheets/d/1ws44kN51WnGwQzOXc8KKRQ93TMgHSqIGb02MRWFel_U/edit?usp=sharing] was: bin/solr adds the URL scheme to the list of arguments via the -scheme flag, but ConfigTool does not support it. We should add support back again and deprecate the option if it is marked for removal. For more details see https://lists.apache.org/thread/t8tnlk8sttjw8wo6q5hooglfbpk5n1vn See also [https://docs.google.com/spreadsheets/d/1ws44kN51WnGwQzOXc8KKRQ93TMgHSqIGb02MRWFel_U/edit?usp=sharing] > ConfigTool does not support -scheme > --- > > Key: SOLR-17459 > URL: https://issues.apache.org/jira/browse/SOLR-17459 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: cli >Affects Versions: 9.7 >Reporter: Christos Malliaridis >Priority: Major > Labels: cli > > bin/solr adds the URL scheme to the list of arguments via the -scheme flag, > but ConfigTool does not support it and throws an "unrecognized option" error. > We should add support back again and deprecate the option if it is marked for > removal. > For more details see > [https://lists.apache.org/thread/t8tnlk8sttjw8wo6q5hooglfbpk5n1vn] > See also > [https://docs.google.com/spreadsheets/d/1ws44kN51WnGwQzOXc8KKRQ93TMgHSqIGb02MRWFel_U/edit?usp=sharing] > -- 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-17442: Resolve -v flag conflict (version, value, verbose) [solr]
malliaridis commented on code in PR #2721:
URL: https://github.com/apache/solr/pull/2721#discussion_r1772845049
##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -148,9 +154,21 @@ public class SolrCLI implements CLIO {
public static final Option OPTION_VERBOSE =
Option.builder("v")
.longOpt("verbose")
+ .deprecated(
+ DeprecatedAttributes.builder()
+ .setForRemoval(true)
+ .setSince("9.8")
+ .setDescription("Use --debug instead")
+ .get())
.required(false)
.desc("Enable verbose command output.")
.build();
+ public static final Option OPTION_DEBUG =
+ Option.builder("d")
+ .longOpt("debug")
+ .required(false)
+ .desc("Enable additional command output.")
+ .build();
Review Comment:
I wasn't sure if we would go for the `--debug` option. Shall we also
deprecate the `-d` for all the other arguments as well in this PR? We use `-d`
in quite a few places and providing the `-d` now for `debug` to all tools may
cause unexpected behavior.
##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -148,9 +154,21 @@ public class SolrCLI implements CLIO {
public static final Option OPTION_VERBOSE =
Review Comment:
Do we mark deprecated options with `@Deprecated`? If so, this would be
beneficial for `OPTION_VERBOSE`.
##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -137,6 +137,12 @@ public class SolrCLI implements CLIO {
public static final Option OPTION_SOLRURL =
Option.builder("url")
.longOpt("solr-url")
+ .deprecated(
+ DeprecatedAttributes.builder()
+ .setForRemoval(true)
+ .setSince("9.7")
+ .setDescription("Use --solr-url instead")
+ .get())
Review Comment:
Leaving this as a note: Splitting `url` from `solr-url` would have a way too
large impact in the rest of the tools, so simply marking both as deprecated is
a good tradeoff.
##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -308,7 +326,8 @@ protected static void checkSslStoreSysProp(String
solrInstallDir, String key) {
}
public static void raiseLogLevelUnlessVerbose(CommandLine cli) {
-if (!cli.hasOption(OPTION_VERBOSE.getOpt())) {
+if (!cli.hasOption((SolrCLI.OPTION_DEBUG.getOpt()))
+|| cli.hasOption(SolrCLI.OPTION_VERBOSE.getOpt())) {
Review Comment:
Have you considered putting both options (verbose and debug) into an
`OptionGroup` (mutually exclusive)? This would allow single option (group)
checks.
--
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-17459) ConfigTool does not support -scheme
[ https://issues.apache.org/jira/browse/SOLR-17459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17459: -- Labels: cli pull-request-available (was: cli) > ConfigTool does not support -scheme > --- > > Key: SOLR-17459 > URL: https://issues.apache.org/jira/browse/SOLR-17459 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: cli >Affects Versions: 9.7 >Reporter: Christos Malliaridis >Priority: Major > Labels: cli, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > bin/solr adds the URL scheme to the list of arguments via the -scheme flag, > but ConfigTool does not support it and throws an "unrecognized option" error. > We should add support back again and deprecate the option if it is marked for > removal. > For more details see > [https://lists.apache.org/thread/t8tnlk8sttjw8wo6q5hooglfbpk5n1vn] > See also > [https://docs.google.com/spreadsheets/d/1ws44kN51WnGwQzOXc8KKRQ93TMgHSqIGb02MRWFel_U/edit?usp=sharing] > -- 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] SOLR-17459: Fix unrecognized option -scheme [solr]
malliaridis opened a new pull request, #2722: URL: https://github.com/apache/solr/pull/2722 https://issues.apache.org/jira/browse/SOLR-17459 # Description This PR is a fix for the "unrecognized option: -scheme" exception thrown when using the `bin/solr config` tool. # Solution The PR fully removes the support of `-s`, `-scheme` and `--scheme`, which was only used in `ConfigTool` before the migration (see #2540). Note that the argument could be set by the users before the migration. With the migration, the URL scheme can no longer be set via the scheme argument and is now set via the `--solr-url` argument or the environment variable `solr.url.scheme` (in case the fallback URL is used). Note that this bug occurs only in `branch_9x` and `branch_9_7` and does not affect `main`. # Tests _No tests were modified or added.__ # Checklist Please review the following and check all that apply: - [X] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) 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, not available for branches on forks living under an organisation) - [ ] I have developed this patch against the `main` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- 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-17442: Resolve -v flag conflict (version, value, verbose) [solr]
epugh commented on PR #2721: URL: https://github.com/apache/solr/pull/2721#issuecomment-2371366107 > I forgot to mention in the ticket that introducing `-d` for `debug` may require further deprecations where `-d` is used for other options as well. I am wondering if we should just stick to `--debug`, I saw a `-d` for directory...it's not a common command to run, so maybe having a short cut isn't that valuable And dealing with the `-d`, well that seems really tough -- 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-17341) Apache Solr website home to include Hybrid and vector-based search references
[ https://issues.apache.org/jira/browse/SOLR-17341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884316#comment-17884316 ] Jason Gerlowski commented on SOLR-17341: Hey [~abenedetti] - SOLR-16295 refreshed the project description that appears on our website, docker images, etc, and the improved language highlights vector search. Did you have other changes in mind when you opened this ticket (new ref guide pages or organization, a "tile" on solr.apache.org, etc.?), or was it mainly around the project descriptions? If the latter, could this be closed out as a duplicate of SOLR-16295? > Apache Solr website home to include Hybrid and vector-based search references > - > > Key: SOLR-17341 > URL: https://issues.apache.org/jira/browse/SOLR-17341 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: website >Reporter: Alessandro Benedetti >Priority: Major > > In the Solr homepage there's no mention of vector-based search and hybrid > capabilities of Apache Solr. > One of the outcomes of the Birds of a Feather from Community Over Code EU > 2024 was that we need to advertise more these powerful functionalities (as > most vector-DB do quite well). -- 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-14673: Add bin/solr stream CLI [solr]
epugh commented on code in PR #2479: URL: https://github.com/apache/solr/pull/2479#discussion_r1773657326 ## solr/solr-ref-guide/modules/query-guide/pages/stream-tool.adoc: ## @@ -71,13 +72,15 @@ CORSAIR ValueSelect 1GB 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) System Me A-DATA V-Series 1GB 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) System Memory - OEM -The `--help` (or simply `-h`) option will output information on its usage (i.e., `bin/solr stream --help)`. - == Using the bin/solr stream Tool +NOTE: The Stream Tool is classified as "experimental". Review Comment: love 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
[jira] [Commented] (SOLR-16503) Switch UpdateShardHandler.getDefaultHttpClient to Jetty HTTP2
[
https://issues.apache.org/jira/browse/SOLR-16503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884423#comment-17884423
]
Jason Gerlowski commented on SOLR-16503:
+1 to this effort!
One additional downside of the "raw" HttpClient usage that I haven't seen
mentioned yet is that it loses out on a lot of the fancy sysprop/env driven
features built into our SolrClients. Case in point: the keystore/truststore
reloading added to SolrJ in SOLR-16743. SolrClients pick up these reloads
automatically, but raw client usage (whether jetty or apache) doesn't. At my
work we saw this cause problems in Solr's PKI code, which uses an
"UpdateShardHandler.getDefaultHttpClient"-provided client.
bq. Is it reasonable approach to introduce another "default" Http2SolrClient
and start replacing usages piece by piece.
I'm not sure I can volunteer to switch over every last usage, but I'm willing
to take a crack at this by adding a new method, deprecating the old, and
swapping a few usages over? (I'd probably start with PKI since, as I mentioned
above, that one caused me some pain at work.)
Is UpdateShardHandler the best place to add the new method, or would another
location (such as 'SolrClientCache') make more sense? It feels a bit fishy to
have big chunks of Solr require access to UpdateShardHandler just so they can
get a client...
> Switch UpdateShardHandler.getDefaultHttpClient to Jetty HTTP2
> -
>
> Key: SOLR-16503
> URL: https://issues.apache.org/jira/browse/SOLR-16503
> Project: Solr
> Issue Type: Sub-task
>Reporter: David Smiley
>Priority: Major
> Labels: pull-request-available
> Attachments: Screenshot 2024-03-16 at 9.14.36 PM.png
>
> Time Spent: 9h
> Remaining Estimate: 0h
>
> Much of Solr's remaining uses of Apache HttpClient (HTTP 1) is due to
> {{org.apache.solr.update.UpdateShardHandler#getDefaultHttpClient}} which
> underlies most Solr-to-Solr connectivity. This also underlies the
> {{{}CoreContainer.getSolrClientCache{}}}. Lets switch to Jetty (HTTP 2).
>
> In SolrClientCache in particular:
> Switch use of CloudLegacySolrClient.Builder to CloudSolrClient.Builder
> Switch use of HttpSolrClient.Builder to Http2SolrClient.Builder
> Undeprecate all the methods here. They should not have been deprecated in
> the first place.
> The constructor: switch from Apache HttpClient to a Jetty HttpClient.
--
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-17460) Error During Collection Migration from Solr 7.0 to Solr 8.4: Missing Files and Shard Restoration Failures
Arda created SOLR-17460: --- Summary: Error During Collection Migration from Solr 7.0 to Solr 8.4: Missing Files and Shard Restoration Failures Key: SOLR-17460 URL: https://issues.apache.org/jira/browse/SOLR-17460 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: hdfs, SolrCloud Affects Versions: 8.4, 7.0 Reporter: Arda I was attempting to migrate a collection with 3 shards from a Solr 7.0 cluster to a Solr 8.4 cluster. The data is stored in HDFS. I followed the backup-restore process but encountered issues with two of the shards during the restoration. h1. *Migration Process:* *1-* *Backup Command:* To avoid timeouts, I initiated the backup with an async parameter: curl -k --negotiate -u : 'https://:/solr/admin/collections?action=BACKUP&name=&collection=x&location=& async=12346' *2- Copy Backup to Local:* After the backup, I copied the data from HDFS to the local filesystem: hdfs dfs --copyToLocal *3- Transfer Backup to New Cluster:* I then copied the backup files from the older Solr node to the newer one: scp -pr @: *4- Prepare New HDFS Path:* On the new Solr cluster, I created a new directory in HDFS and adjusted ownership: hdfs dfs -mkdir hdfs dfs -chown solr:solr *5- Copy Backup to New HDFS Location:* I transferred the backup data from local to the new HDFS path: hdfs dfs --copyFromLocal *6- Restore Collection:* Finally, I ran the restore command: curl -k --negotiate -u : 'https://:/solr/admin/collections?action=RESTORE&name=&collection=x&location=& async=12345' h1. *Issue:* After the restore process completed, I found that two of the shards could not be restored. The logs displayed the following errors: *Error During Shard Restoration:* ERROR [c: s: shard2 r:core_node5 x: : _shard2_replica_n4] o.a.s.h.RequestHandlerBase org.apache.solr.common. SolrException: Error CREATEing SolrCore '_shard2_replica_n4': Unable to create core [:_shard2_replica_n4] Caused by: org.apache.solr.handler.component.QueryDocAuthorizationComponent. *FileNotFoundException and Index Corruption:* WARN (parallelCoreAdminExecutor-6-thread-7-processing-n::_solrx:_shard2 _replica_n1 RESTORECORE) [x:_shard2_replica_n1] o.a.s.h. RestoreCore Could not switch to restored index. Rolling back to the current index => org.apache.lucene.index.CorruptindexException: Unexpected file read error while reading index. (resource=BufferedChecksumIndexInput(segments_1g9dk)) Caused by: java.io. FileNotFoundException: File does not exist: hdfs:///core_node2/data/restore/ It appears that Solr is looking for a file in HDFS that doesn't exist, despite no manual deletions being made. I cannot determine why these specific shards failed to restore, or why the system is unable to locate the required files. Expected Behavior: The backup and restore process should complete without errors, and all shards should be restored successfully to the new cluster. Actual Behavior: Two shards failed to restore, with errors related to missing files and index corruption. -- 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-17460) Error During Collection Migration from Solr 7.0 to Solr 8.4: Missing Files and Shard Restoration Failures
[ https://issues.apache.org/jira/browse/SOLR-17460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arda updated SOLR-17460: Description: I was attempting to migrate a collection with 3 shards from a Solr 7.0 cluster to a Solr 8.4 cluster. The data is stored in HDFS. I followed the backup-restore process but encountered issues with two of the shards during the restoration. h1. *Migration Process:* *1-* *Backup Command:* To avoid timeouts, I initiated the backup with an async parameter: curl -k --negotiate -u : 'https://:/solr/admin/collections?action=BACKUP&name=&collection=x&location=& async=12346' *2- Copy Backup to Local:* After the backup, I copied the data from HDFS to the local filesystem: hdfs dfs --copyToLocal *3- Transfer Backup to New Cluster:* I then copied the backup files from the older Solr node to the newer one: scp -pr @: *4- Prepare New HDFS Path:* On the new Solr cluster, I created a new directory in HDFS and adjusted ownership: hdfs dfs -mkdir hdfs dfs -chown solr:solr *5- Copy Backup to New HDFS Location:* I transferred the backup data from local to the new HDFS path. Before that, I deleted "queryDocAuthorization" parts from solrconfig.xml file to become compatible with the newer version. hdfs dfs --copyFromLocal *6- Restore Collection:* Finally, I ran the restore command: curl -k --negotiate -u : 'https://:/solr/admin/collections?action=RESTORE&name=&collection=x&location=& async=12345' h1. *Issue:* After the restore process completed, I found that two of the shards could not be restored. The logs displayed the following errors: *Error During Shard Restoration:* ERROR [c: s: shard2 r:core_node5 x: : _shard2_replica_n4] o.a.s.h.RequestHandlerBase org.apache.solr.common. SolrException: Error CREATEing SolrCore '_shard2_replica_n4': Unable to create core [:_shard2_replica_n4] Caused by: org.apache.solr.handler.component.QueryDocAuthorizationComponent. *FileNotFoundException and Index Corruption:* WARN (parallelCoreAdminExecutor-6-thread-7-processing-n::_solrx:_shard2 _replica_n1 RESTORECORE) [x:_shard2_replica_n1] o.a.s.h. RestoreCore Could not switch to restored index. Rolling back to the current index => org.apache.lucene.index.CorruptindexException: Unexpected file read error while reading index. (resource=BufferedChecksumIndexInput(segments_1g9dk)) Caused by: java.io. FileNotFoundException: File does not exist: hdfs:///core_node2/data/restore/ It appears that Solr is looking for a file in HDFS that doesn't exist, despite no manual deletions being made. I cannot determine why these specific shards failed to restore, or why the system is unable to locate the required files. Expected Behavior: The backup and restore process should complete without errors, and all shards should be restored successfully to the new cluster. Actual Behavior: Two shards failed to restore, with errors related to missing files and index corruption. was: I was attempting to migrate a collection with 3 shards from a Solr 7.0 cluster to a Solr 8.4 cluster. The data is stored in HDFS. I followed the backup-restore process but encountered issues with two of the shards during the restoration. h1. *Migration Process:* *1-* *Backup Command:* To avoid timeouts, I initiated the backup with an async parameter: curl -k --negotiate -u : 'https://:/solr/admin/collections?action=BACKUP&name=&collection=x&location=& async=12346' *2- Copy Backup to Local:* After the backup, I copied the data from HDFS to the local filesystem: hdfs dfs --copyToLocal *3- Transfer Backup to New Cluster:* I then copied the backup files from the older Solr node to the newer one: scp -pr @: *4- Prepare New HDFS Path:* On the new Solr cluster, I created a new directory in HDFS and adjusted ownership: hdfs dfs -mkdir hdfs dfs -chown solr:solr *5- Copy Backup to New HDFS Location:* I transferred the backup data from local to the new HDFS path: hdfs dfs --copyFromLocal *6- Restore Collection:* Finally, I ran the restore command: curl -k --negotiate -u : 'https://:/solr/admin/collections?action=RESTORE&name=&collection=x&location=& async=12345' h1. *Issue:* After the restore process completed, I found that two of the shards could not be restored. The logs displayed the following errors: *Error During Shard Restoration:* ERROR [c: s: shard2 r:core_node5 x: : _shard2_replica_n4] o.a.s.h.RequestHandlerBase org.apache.solr.common. SolrException: Error CREATEing SolrCore '_shard2_replica_n4': Unable to create core [:_shard2_replica_n4] Caused by: org.apache.solr.handler.component.QueryDocAuthorizationComponent. *FileNotFoundException and Index Corruption:* WARN (parallelCoreAdminExecutor-6-thread-7-processing-n::_solrx:_shard2 _replica_n1 RESTORECORE) [x:_shard2_replica_n1] o.a.s.h. RestoreCore Could not switch to restored index. Rolling back to the current index => org.apache.
[jira] [Commented] (SOLR-17460) Error During Collection Migration from Solr 7.0 to Solr 8.4: Missing Files and Shard Restoration Failures
[ https://issues.apache.org/jira/browse/SOLR-17460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884426#comment-17884426 ] Arda commented on SOLR-17460: - To successfully migrate the collection with all data intact, I followed these steps: *1. Prepare the Collection Configuration:* First, I retrieved the Solr collection's configuration files from the Solr 7.0 cluster and modified them to be compatible with Solr 8.4. I then created the new collection on the Solr 8.4 cluster without any data, using the updated configuration. *2. Copy Shard Core Nodes Locally:* I copied each shard’s core nodes from the HDFS path of the Solr 7.0 cluster to a local directory. Using the Solr Web UI, I identified which nodes corresponded to each shard and replica for the collection. Note that the core node paths may differ for each collection. Here’s an example of the commands used: _# Shard 1, 2, and 3_ hdfs dfs --copyToLocal /core_node1 _# Shard 1_ hdfs dfs --copyToLocal /core_node2 _# Shard 2_ hdfs dfs --copyToLocal /core_node3 _# Shard 3_ _# Replica nodes_ hdfs dfs --copyToLocal /core_node6 _# Replica 1_ hdfs dfs --copyToLocal /core_node8 _# Replica 2_ hdfs dfs --copyToLocal /core_node10 _# Replica 3_ After copying the core node files locally, I transferred them to the Solr 8.4 cluster. *3. Copy Shard Core Nodes to HDFS on the New Cluster:* I copied the shard core node files into the appropriate HDFS directory on the new Solr 8.4 cluster. *Important:* The shard core nodes must be copied into the exact corresponding location. For example, if shard 1 was stored in *_core_node1_* in the old cluster and is now assigned to *_core_node5_* in the new cluster, you must copy the data from *_core_node1_* to *_core_node5._* Example commands: _# Copy shard 1, 2, and 3 core nodes_ hdfs dfs -put /core_node1 /core_node5 _# Shard 1_ hdfs dfs -put /core_node2 /core_node6 _# Shard 2_ hdfs dfs -put /core_node3 /core_node7 _# Shard 3_ _# Copy replica core nodes_ hdfs dfs -put /core_node6 /core_node11 _# Replica 1_ hdfs dfs -put /core_node8 /core_node12 _# Replica 2_ hdfs dfs -put /core_node10 /core_node9 _# Replica 3_ *4. Adjust Ownership in HDFS:* I changed the ownership of the collection’s HDFS path on the new cluster to ensure Solr had the necessary permissions to access the data. hdfs dfs -chown -R solr:solr To verify that the files were correctly copied, I compared the file sizes on both clusters using the following command: hdfs dfs -du -s -h -v -x *5. Reload the Collection:* Finally, I reloaded the collection via the Solr Web UI on the new Solr 8.4 cluster. To confirm the successful migration of all data, I queried the collection and verified that the document count matched the original. With these steps, I was able to migrate the entire collection along with all data. You can check the document count by running a simple query to verify that the migration was successful. > Error During Collection Migration from Solr 7.0 to Solr 8.4: Missing Files > and Shard Restoration Failures > - > > Key: SOLR-17460 > URL: https://issues.apache.org/jira/browse/SOLR-17460 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: hdfs, SolrCloud >Affects Versions: 7.0, 8.4 >Reporter: Arda >Priority: Minor > Labels: backup, restore > > I was attempting to migrate a collection with 3 shards from a Solr 7.0 > cluster to a Solr 8.4 cluster. The data is stored in HDFS. I followed the > backup-restore process but encountered issues with two of the shards during > the restoration. > h1. *Migration Process:* > *1-* *Backup Command:* To avoid timeouts, I initiated the backup with an > async parameter: > curl -k --negotiate -u : > 'https://:/solr/admin/collections?action=BACKUP&name=&collection=x&location=& > async=12346' > *2- Copy Backup to Local:* After the backup, I copied the data from HDFS to > the local filesystem: > hdfs dfs --copyToLocal > *3- Transfer Backup to New Cluster:* I then copied the backup files from the > older Solr node to the newer one: > scp -pr @: > *4- Prepare New HDFS Path:* On the new Solr cluster, I created a new > directory in HDFS and adjusted ownership: > hdfs dfs -mkdir > hdfs dfs -chown solr:solr > *5- Copy Backup to New HDFS Location:* I transferred the backup data from > local to the new HDFS path. Before that, I deleted > "queryDocAuthorization" parts from solrconfig.xml file to become > compatible with the newer version. > hdfs dfs --copyFromLocal > *6- Restore Collection:* Finally, I ran the restore command: > curl -k --negotiate -u : > 'https://:/solr/admin/collections?action=RESTORE&name=&c
[jira] [Updated] (SOLR-17460) Error During Collection Migration from Solr 7.0 to Solr 8.4: Missing Files and Shard Restoration Failures
[ https://issues.apache.org/jira/browse/SOLR-17460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arda updated SOLR-17460: Description: I was attempting to migrate a collection with 3 shards from a Solr 7.0 cluster to a Solr 8.4 cluster. The data is stored in HDFS. I followed the backup-restore process but encountered issues with two of the shards during the restoration. h1. *Migration Process:* *1-* *Backup Command:* To avoid timeouts, I initiated the backup with an async parameter: curl -k --negotiate -u : 'https://:/solr/admin/collections?action=BACKUP&name=&collection=x&location=& async=12346' *2- Copy Backup to Local:* After the backup, I copied the data from HDFS to the local filesystem: hdfs dfs --copyToLocal *3- Transfer Backup to New Cluster:* I then copied the backup files from the older Solr node to the newer one: scp -pr @: *4- Prepare New HDFS Path:* On the new Solr cluster, I created a new directory in HDFS and adjusted ownership: hdfs dfs -mkdir hdfs dfs -chown solr:solr *5- Copy Backup to New HDFS Location:* I transferred the backup data from local to the new HDFS path. Before that, I deleted "queryDocAuthorization" parts from solrconfig.xml file to become compatible with the newer version. hdfs dfs --copyFromLocal *6- Restore Collection:* Finally, I ran the restore command: curl -k --negotiate -u : 'https://:/solr/admin/collections?action=RESTORE&name=&collection=x&location=& async=12345' h1. *Issue:* After the restore process completed, I found that two of the shards could not be restored. The logs displayed the following errors: *Error During Shard Restoration:* ERROR [c: s: shard2 r:core_node5 x: : _shard2_replica_n4] o.a.s.h.RequestHandlerBase org.apache.solr.common. SolrException: Error CREATEing SolrCore '_shard2_replica_n4': Unable to create core [:_shard2_replica_n4] Caused by: org.apache.solr.handler.component.QueryDocAuthorizationComponent. *FileNotFoundException and Index Corruption:* WARN (parallelCoreAdminExecutor-6-thread-7-processing-n::_solrx:_shard2 _replica_n1 RESTORECORE) [x:_shard2_replica_n1] o.a.s.h. RestoreCore Could not switch to restored index. Rolling back to the current index => org.apache.lucene.index.CorruptindexException: Unexpected file read error while reading index. (resource=BufferedChecksumIndexInput(segments_1g9dk)) Caused by: java.io. FileNotFoundException: File does not exist: hdfs:///core_node2/data/restore/ It appears that Solr is looking for a file in HDFS that doesn't exist, despite no manual deletions being made. I cannot determine why these specific shards failed to restore, or why the system is unable to locate the required files. *Expected Behavior:* The backup and restore process should complete without errors, and all shards should be restored successfully to the new cluster. *Actual Behavior:* Two shards failed to restore, with errors related to missing files and index corruption. was: I was attempting to migrate a collection with 3 shards from a Solr 7.0 cluster to a Solr 8.4 cluster. The data is stored in HDFS. I followed the backup-restore process but encountered issues with two of the shards during the restoration. h1. *Migration Process:* *1-* *Backup Command:* To avoid timeouts, I initiated the backup with an async parameter: curl -k --negotiate -u : 'https://:/solr/admin/collections?action=BACKUP&name=&collection=x&location=& async=12346' *2- Copy Backup to Local:* After the backup, I copied the data from HDFS to the local filesystem: hdfs dfs --copyToLocal *3- Transfer Backup to New Cluster:* I then copied the backup files from the older Solr node to the newer one: scp -pr @: *4- Prepare New HDFS Path:* On the new Solr cluster, I created a new directory in HDFS and adjusted ownership: hdfs dfs -mkdir hdfs dfs -chown solr:solr *5- Copy Backup to New HDFS Location:* I transferred the backup data from local to the new HDFS path. Before that, I deleted "queryDocAuthorization" parts from solrconfig.xml file to become compatible with the newer version. hdfs dfs --copyFromLocal *6- Restore Collection:* Finally, I ran the restore command: curl -k --negotiate -u : 'https://:/solr/admin/collections?action=RESTORE&name=&collection=x&location=& async=12345' h1. *Issue:* After the restore process completed, I found that two of the shards could not be restored. The logs displayed the following errors: *Error During Shard Restoration:* ERROR [c: s: shard2 r:core_node5 x: : _shard2_replica_n4] o.a.s.h.RequestHandlerBase org.apache.solr.common. SolrException: Error CREATEing SolrCore '_shard2_replica_n4': Unable to create core [:_shard2_replica_n4] Caused by: org.apache.solr.handler.component.QueryDocAuthorizationComponent. *FileNotFoundException and Index Corruption:* WARN (parallelCoreAdminExecutor-6-thread-7-processing-n::_solrx:_shard2 _replica_n1 RESTORECORE) [x:_sha
Re: [PR] SOLR-14673: Add bin/solr stream CLI [solr]
gerlowskija commented on code in PR #2479: URL: https://github.com/apache/solr/pull/2479#discussion_r1773483777 ## solr/solr-ref-guide/modules/query-guide/pages/stream-tool.adoc: ## @@ -0,0 +1,167 @@ += Stream Tool +// 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. + +The Stream tool allows you to run a xref:streaming-expressions.adoc[] and see the results from the command line. +It is very similar to the xref:stream-screen.adoc[], but is part of the `bin/solr` CLI. + +To run it, open a window and enter: + +[,console] + +$ bin/solr stream --header -c techproducts --delimiter=\| 'search(techproducts,q="name:memory",fl="name,price")' + + +This will run the provided streaming expression on the `techproducts` collection and produce: + +[,console] + +name|price +CORSAIR XMS 2GB (2 x 1GB) 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) Dual Channel Kit System Memory - Retail|185.0 +CORSAIR ValueSelect 1GB 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) System Memory - Retail|74.99 +A-DATA V-Series 1GB 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) System Memory - OEM| + + +TIP: Notice how we used the pipe character (|) as the delimiter? It required a backslash for escaping it so it wouldn't be treated as a pipe with in the shell script. + +You can also specify a file with the suffix `.expr` containing your streaming expression. +This is useful for longer expressions or if you having command line parsing issues with your expression. + +Assuming you have create the file `stream.expr` with the contents: + + +# Stream a search + +search( + techproducts, + q="name:memory", + fl="name,price", + sort="price desc" +) + + +Then you can run it on the Solr collection `techproducts`, specifying you want a header row: + +[,console] + +$ bin/solr stream --header -c techproducts stream.expr + + +And this will produce: + +[,console] + +name price +CORSAIR XMS 2GB (2 x 1GB) 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) Dual Channel Kit System Memory - Retail 185.0 +CORSAIR ValueSelect 1GB 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) System Memory - Retail 74.99 +A-DATA V-Series 1GB 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) System Memory - OEM + + +The `--help` (or simply `-h`) option will output information on its usage (i.e., `bin/solr stream --help)`. + +== Using the bin/solr stream Tool + +To use the tool you need to provide the streaming expression either inline as the last argument, or provide a file ending in `.expr` that contains the expression. + +The basic usage of `bin/solr stream` is: + +[source,plain] + +usage: bin/solr stream [--array-delimiter ] [-c ] [--delimiter ] [-f ] [--header] + [-u ] [-url ] [--workers ] [-z ] + +List of options: +--array-delimiterThe delimiter multi-valued fields. (default=|) + -c,--nameName of the collection to execute on if workers are 'solr'. Required for 'solr' +worker. +--delimiter The output delimiter. (default=tab). + -f,--fieldsThe fields in the tuples to output. (defaults to fields in the first tuple of result +set). +--headerWhether or not to include a header line. (default=false) + -u,--credentials Credentials in the format username:password. Example: --credentials solr:SolrRocks + -url,--solr-url Base Solr URL, which can be used to determine the zk-host if that's not known; +defaults to: http://localhost:8983. + -e,--executionExecution context is either 'local' or 'solr'. Default is 'solr' Review Comment: I noodled on this a bit but still couldn't come up with anything I liked better, so maybe you picked the best option. +1 for the current enum values with the "(i.e. CLI process)" clarification you suggested. -- 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 Infra
Re: [PR] SOLR-14673: Add bin/solr stream CLI [solr]
gerlowskija commented on code in PR #2479: URL: https://github.com/apache/solr/pull/2479#discussion_r1773493224 ## solr/solr-ref-guide/modules/query-guide/pages/stream-tool.adoc: ## @@ -71,13 +72,15 @@ CORSAIR ValueSelect 1GB 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) System Me A-DATA V-Series 1GB 184-Pin DDR SDRAM Unbuffered DDR 400 (PC 3200) System Memory - OEM -The `--help` (or simply `-h`) option will output information on its usage (i.e., `bin/solr stream --help)`. - == Using the bin/solr stream Tool +NOTE: The Stream Tool is classified as "experimental". Review Comment: Might be worth putting this at the top of the page. Seems a little "buried" as-is. -- 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-17442: Resolve -v flag conflict (version, value, verbose) [solr]
epugh commented on code in PR #2721:
URL: https://github.com/apache/solr/pull/2721#discussion_r1773412097
##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -148,9 +154,21 @@ public class SolrCLI implements CLIO {
public static final Option OPTION_VERBOSE =
Review Comment:
hey, I hadn't thought about that useGood catch, and we should.
--
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-16295) Modernize and Standardize Solr description across all platforms
[ https://issues.apache.org/jira/browse/SOLR-16295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski resolved SOLR-16295. Fix Version/s: 9.7 Assignee: Jason Gerlowski (was: Eric Pugh) Resolution: Fixed Closing this out, as the last (dockerhub) PR has been merged! Not totally sure what to put as a "Fix Version" here, as many of the changes in this JIRA aren't tied to a versioned artifact, but I ended up going with 9.7 as this did change some README's that will ship in our 9.7 artifacts. > Modernize and Standardize Solr description across all platforms > --- > > Key: SOLR-16295 > URL: https://issues.apache.org/jira/browse/SOLR-16295 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Houston Putman >Assignee: Jason Gerlowski >Priority: Major > Labels: pull-request-available > Fix For: 9.7 > > Time Spent: 1h > Remaining Estimate: 0h > > Currently everywhere we have a page on "Solr", we have a short description on > what the project/product is. They are all roughly the same, but we should try > to improve this language and standardize it everywhere. > The places I can think of currently are: > * [solr.apache.org|https://solr.apache.org/] > * [Ref Guide|https://solr.apache.org/guide/solr/latest/] > * [Github - Solr|https://github.com/apache/solr] > * [DockerHub - Solr|https://hub.docker.com/_/solr] > * [ArtifactHub - Solr|https://artifacthub.io/packages/helm/apache-solr/solr] > The Solr Operator pages don't really give a Solr description, which is fine. > Please comment if I forgot any, so that we can have a comprehensive list. > Once we agree on the standardized language, we can then update it everywhere > it needs to go (since the above list are managed in a variety of places). -- 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] Benchmark: HTTP2 fix cancel_stream_error [solr]
dsmiley commented on PR #2612: URL: https://github.com/apache/solr/pull/2612#issuecomment-2371983637 Yes; our versions are in `versions.props` -- 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-17442: Resolve -v flag conflict (version, value, verbose) [solr]
epugh commented on PR #2721: URL: https://github.com/apache/solr/pull/2721#issuecomment-2371420084 > > I forgot to mention in the ticket that introducing `-d` for `debug` may require further deprecations where `-d` is used for other options as well. > > I am wondering if we should just stick to `--debug`, I saw a `-d` for directory... it's not a common command to run, so maybe having a short cut isn't that valuable And dealing with the `-d`, well that seems really tough I checked what Docker does, just for run, and they use `-D`: ``` -D, --debug Enable debug mode ``` I am kind of leaning towards avoiding the whole `-d` topic by removing 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] SOLR-17442: Resolve -v flag conflict (version, value, verbose) [solr]
malliaridis commented on PR #2721: URL: https://github.com/apache/solr/pull/2721#issuecomment-2371449034 `-d` is one of the conflicting flags that we have to resolve anyway. I would prefer only the long variant in that case, which may be either `debug` or `verbose`, both are fine and when the user uses either of them he is already comitted to be more explicit with the CLI, if that makes sense. -- 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] Add scripts to fetch+prepare solr-community data [solr-sandbox]
gerlowskija merged PR #111: URL: https://github.com/apache/solr-sandbox/pull/111 -- 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: [I] BalanceReplicas called even when PopulatePodsOnScaleUp and VacatePodsOnScaleDown are false [solr-operator]
HoustonPutman commented on issue #724: URL: https://github.com/apache/solr-operator/issues/724#issuecomment-2371628651 It definitely calls it when doing a rolling restart of an ephemeral collection, but that's because we are moving replicas around anyways. We can definitely document that better, but I'm not sure I'd want to remove that feature. Can you describe the other scenarios in which its called? -- 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-16470) Create V2 equivalent of V1 Replication: Get IndexVersion, Get FileStream, Get File List
[
https://issues.apache.org/jira/browse/SOLR-16470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1788#comment-1788
]
Matthew Biscocho commented on SOLR-16470:
-
[~gerlowskija] Started to look into the filecontent API and noticed it was
failing with a stack trace. Doing some digging, I believe I found a regression
due to this [commit.|https://github.com/apache/solr/pull/1867] Don't fully
understand what this does yet but was probably not caught because there are no
tests around the filecontent command on this replication API. This will
probably need a fix before migrating this API over to V2
{code:java}
{
"error":{
"msg":"java.lang.IllegalAccessException: access violation: class
org.apache.solr.handler.ReplicationHandler$DirectoryFileStream, from public
Lookup",
"trace":"java.lang.RuntimeException: java.lang.IllegalAccessException:
access violation: class
org.apache.solr.handler.ReplicationHandler$DirectoryFileStream, from public
Lookup\n\tat
org.apache.solr.common.util.Utils.getReflectWriter(Utils.java:928)\n\tat
org.apache.solr.common.util.TextWriter.writeVal(TextWriter.java:114)\n\tat
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:213)\n\tat
org.apache.solr.common.util.TextWriter.writeVal(TextWriter.java:48)\n\tat
org.apache.solr.common.util.JsonTextWriter.writeNamedListAsMapWithDups(JsonTextWriter.java:404)\n\tat
org.apache.solr.common.util.JsonTextWriter.writeNamedList(JsonTextWriter.java:312)\n\tat
org.apache.solr.response.JacksonJsonWriter$WriterImpl.writeResponse(JacksonJsonWriter.java:88)\n\tat
org.apache.solr.response.JacksonJsonWriter.write(JacksonJsonWriter.java:50)\n\tat
org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:55)\n\tat
org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:1012)\n\tat
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:600)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:243)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:204)\n\tat
org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:241)\n\tat
org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:209)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:198)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)\n\tat
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)\n\tat
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1580)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:221)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1384)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:176)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:484)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1553)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:174)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1306)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:129)\n\tat
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)\n\tat
org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:228)\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:141)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)\n\tat
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:301)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)\n\tat
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:822)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:563)\n\tat
org.eclipse.jetty.server.HttpChannel$RequestDispatchable.dispatch(HttpChannel.java:1598)\n\tat
org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:753)\n\tat
org.eclipse.jetty.server.HttpChannel.handle(HttpCha
Re: [PR] SOLR-17406: Introduce Version Catalogs [solr]
dsmiley commented on PR #2706: URL: https://github.com/apache/solr/pull/2706#issuecomment-2373053917 > spotless and tidy are added to run on build files too Awesome! -- 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-17406: Introduce Version Catalogs [solr]
dsmiley commented on code in PR #2706:
URL: https://github.com/apache/solr/pull/2706#discussion_r1774499355
##
build.gradle:
##
@@ -139,7 +143,7 @@ apply from: file('gradle/maven/defaults-maven.gradle')
// IDE support, settings and specials.
apply from: file('gradle/ide/intellij-idea.gradle')
-apply from: file('gradle/ide/eclipse.gradle')
+// apply from: file('gradle/ide/eclipse.gradle')
Review Comment:
do we remove it then?
##
gradle/node.gradle:
##
@@ -16,7 +16,7 @@
*/
configure([project(":solr:packaging"), project(":solr:solr-ref-guide"),
project(":solr:webapp")]) {
-apply plugin: "com.github.node-gradle.node"
+apply plugin: libs.plugins.nodegradle.node.get().pluginId
Review Comment:
TBH I liked it as it was -- a well known string instead of some dotted
namespace from the toml that we invent for each dependency.
##
gradle/libs.versions.toml:
##
@@ -0,0 +1,432 @@
+# 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.
+[versions]
+adobe-testing-s3mock = "2.17.0"
+amazon-awssdk = "2.26.19"
+# @keep Antora version used in ref-guide
+antora = "3.1.4"
+# @keep Most recent commit as of 2022-06-24, this repo does not have tags
+antora-default-ui = "51ad811622394027afb4e182c2fdabc235ae04dd"
+# @keep Antora Lunr extensions version used in ref-guide
+antora-lunr-extension = "1.0.0-alpha.8"
+apache-calcite = "1.37.0"
+apache-calcite-avatica = "1.25.0"
+apache-commons-collections4 = "4.4"
+apache-commons-compress = "1.26.1"
+apache-commons-configuration2 = "2.11.0"
+apache-commons-exec = "1.4.0"
+apache-commons-lang3 = "3.15.0"
+apache-commons-math3 = "3.6.1"
+# @keep for version alignment
+apache-commons-text = "1.12.0"
+apache-curator = "5.7.0"
+apache-hadoop = "3.3.6"
+apache-hadoop-thirdparty = "1.2.0"
+apache-httpcomponents-httpclient = "4.5.14"
+apache-httpcomponents-httpcore = "4.4.16"
+apache-httpcomponents-httpmime = "4.5.14"
+apache-kerby = "1.0.1"
+apache-log4j = "2.21.0"
+apache-lucene = "9.11.1"
+apache-opennlp = "1.9.4"
+apache-poi = "5.2.2"
+apache-rat = "0.15"
+apache-tika = "1.28.5"
+apache-tomcat = "6.0.53"
+apache-zookeeper = "3.9.2"
+aqute-bnd = "6.4.1"
+# @keep Asciidoctor mathjax version used in ref-guide
+asciidoctor-mathjax = "0.0.9"
+# @keep Asciidoctor tabs version used in ref-guide
+asciidoctor-tabs = "1.0.0-beta.6"
+bc-jose4j = "0.9.6"
+benmanes-caffeine = "3.1.8"
+benmanes-versions = "0.51.0"
+bouncycastle = "1.78.1"
+# @keep Browserify version used in ref-guide
+browserify = "17.0.0"
+carrot2-core = "4.5.1"
+carrotsearch-dependencychecks = "0.0.9"
+carrotsearch-hppc = "0.10.0"
+carrotsearch-randomizedtesting = "2.8.1"
+# @keep for version alignment
+checkerframework = "3.44.0"
+codehaus-woodstox = "4.2.2"
+commons-cli = "1.9.0"
+commons-codec = "1.17.1"
+commons-collections = "3.2.2"
+commons-io = "2.15.1"
+cutterslade-analyze = "1.10.0"
+cybozulabs-langdetect = "1.1-20120112"
+diffplug-spotless = "6.5.2"
+dropwizard-metrics = "4.2.26"
+eclipse-ecj = "3.33.0"
+eclipse-jetty = "10.0.22"
+eclipse-jettytoolchain = "4.0.6"
+# @keep jgit version used by git-statuts.gradle
+eclipse-jgit = "6.7.0.202309050840-r"
+fasterxml = "2.17.2"
+fasterxml-woodstox = "6.7.0"
+# @keep Flexmark used in classpath
+flexmark = "0.64.8"
+google-api-gax = "2.33.0"
+# @keep for version alignment
+google-api-grpc-proto = "2.42.0"
+google-auth = "1.19.0"
+# @keep for version alignment
+google-autovalue = "1.10.4"
+google-cloud-bom = "0.224.0"
+google-cloud-core = "2.23.0"
+google-cloud-nio = "0.127.3"
+google-cloud-storage = "2.27.0"
+google-errorprone = "2.28.0"
+# @keep for version alignment
+google-failureaccess = "1.0.2"
+# @keep for version alignment
+google-gson = "2.11.0"
+google-guava = "33.1.0-jre"
+# @keep This is GJF version for spotless/ tidy.
+google-javaformat = "1.18.1"
+# @keep for version alignment
+google-protobuf = "3.25.3"
+google-re2j = "1.7"
+# @keep Gradle version to run the build
+gradle = "8.4"
+grpc = "1.65.1"
+# @keep Gulp version used in ref-guide
+gulp-cli = "2.3.0"
+hamcrest = "2.2"
+hk2 = "3.0.5"
+hsqldb = "2.7.2"
+ibm-icu = "74.2"
+immutables-valueannotations = "2.10.1"
+j256-simplemagic = "1.17"
+jakarta-annotation = "2.1.1"
+jakarta-inject = "2.0.1"
+jakarta-ws = "3.1.0"
+
