[jira] [Comment Edited] (SOLR-13502) Investigate using something other than ZooKeeper's "4 letter words" for the admin UI status

[John Durham (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842199#comment-17842199
 ] 

John Durham edited comment on SOLR-13502 at 4/30/24 2:11 AM:
-

I think having it be an addition to 4lw makes sense. I'll work towards making 
it work with either the original 4lw or admin server.


was (Author: jdurham):
I think having it be in addition to 4lw makes sense. I'll work towards making 
it work with either the original 4lw or admin server.

> Investigate using something other than ZooKeeper's "4 letter words" for the 
> admin UI status
> ---
>
> Key: SOLR-13502
> URL: https://issues.apache.org/jira/browse/SOLR-13502
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: Erick Erickson
>Priority: Major
>
> ZooKeeper 3.5.5 requires a whitelist of allowed "4 letter words". The only 
> place I see on a quick look at the Solr code where 4lws are used is in the 
> admin UI "ZK Status" link.
> In order to use the admin UI "ZK Status" link, users will have to modify 
> their zoo.cfg file with
> {code}
> 4lw.commands.whitelist=mntr,conf,ruok
> {code}
> This JIRA is to see if there are alternatives to using 4lw for the admin UI.
> This depends on SOLR-8346. If we find an alternative, we need to remove the 
> additions to the ref guide that mention changing zoo.cfg (just scan for 4lw 
> in all the .adoc files) and remove SolrZkServer.ZK_WHITELIST_PROPERTY and all 
> references to it (SolrZkServer and SolrTestCaseJ4).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

[jira] [Comment Edited] (SOLR-13502) Investigate using something other than ZooKeeper's "4 letter words" for the admin UI status

[John Durham (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842199#comment-17842199
 ] 

John Durham edited comment on SOLR-13502 at 4/30/24 12:33 AM:
--

I think having it be in addition to 4lw makes sense. I'll work towards making 
it work with either the original 4lw or admin server.


was (Author: jdurham):
I think having it be in addition to 4lw makes sense. I'll work towards making 
it work with either the original 4lw or admin server.

So far I'm not seeing SSL supported on admin server. However, with admin server 
being served on a separate port (8080 default) from the regular client 
connections (port 2181), at least some kind of monitoring/metrics will be 
available even if SSL isn't currently available.

> Investigate using something other than ZooKeeper's "4 letter words" for the 
> admin UI status
> ---
>
> Key: SOLR-13502
> URL: https://issues.apache.org/jira/browse/SOLR-13502
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: Erick Erickson
>Priority: Major
>
> ZooKeeper 3.5.5 requires a whitelist of allowed "4 letter words". The only 
> place I see on a quick look at the Solr code where 4lws are used is in the 
> admin UI "ZK Status" link.
> In order to use the admin UI "ZK Status" link, users will have to modify 
> their zoo.cfg file with
> {code}
> 4lw.commands.whitelist=mntr,conf,ruok
> {code}
> This JIRA is to see if there are alternatives to using 4lw for the admin UI.
> This depends on SOLR-8346. If we find an alternative, we need to remove the 
> additions to the ref guide that mention changing zoo.cfg (just scan for 4lw 
> in all the .adoc files) and remove SolrZkServer.ZK_WHITELIST_PROPERTY and all 
> references to it (SolrZkServer and SolrTestCaseJ4).



--
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-13502) Investigate using something other than ZooKeeper's "4 letter words" for the admin UI status

[John Durham (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842199#comment-17842199
 ] 

John Durham commented on SOLR-13502:


I think having it be in addition to 4lw makes sense. I'll work towards making 
it work with either the original 4lw or admin server.

So far I'm not seeing SSL supported on admin server. However, with admin server 
being served on a separate port (8080 default) from the regular client 
connections (port 2181), at least some kind of monitoring/metrics will be 
available even if SSL isn't currently available.

> Investigate using something other than ZooKeeper's "4 letter words" for the 
> admin UI status
> ---
>
> Key: SOLR-13502
> URL: https://issues.apache.org/jira/browse/SOLR-13502
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Reporter: Erick Erickson
>Priority: Major
>
> ZooKeeper 3.5.5 requires a whitelist of allowed "4 letter words". The only 
> place I see on a quick look at the Solr code where 4lws are used is in the 
> admin UI "ZK Status" link.
> In order to use the admin UI "ZK Status" link, users will have to modify 
> their zoo.cfg file with
> {code}
> 4lw.commands.whitelist=mntr,conf,ruok
> {code}
> This JIRA is to see if there are alternatives to using 4lw for the admin UI.
> This depends on SOLR-8346. If we find an alternative, we need to remove the 
> additions to the ref guide that mention changing zoo.cfg (just scan for 4lw 
> in all the .adoc files) and remove SolrZkServer.ZK_WHITELIST_PROPERTY and all 
> references to it (SolrZkServer and SolrTestCaseJ4).



--
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-6572 Trim whitespace for shards.tolerant and leaderUrl [solr]

[via GitHub]

github-actions[bot] commented on PR #2311:
URL: https://github.com/apache/solr/pull/2311#issuecomment-2083897068

   This PR had no visible activity in the past 60 days, labeling it as stale. 
Any new activity will remove the stale label. To attract more reviewers, please 
tag someone or notify the d...@solr.apache.org mailing list. Thank you for your 
contribution!


-- 
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-10059] Handle appended fq params with macros in distributed requests [solr]

[via GitHub]

github-actions[bot] commented on PR #2303:
URL: https://github.com/apache/solr/pull/2303#issuecomment-2083897095

   This PR had no visible activity in the past 60 days, labeling it as stale. 
Any new activity will remove the stale label. To attract more reviewers, please 
tag someone or notify the d...@solr.apache.org mailing list. Thank you for your 
contribution!


-- 
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-17244 - initial cut at an orientation for prospective release managers [solr]

[via GitHub]

janhoy commented on code in PR #2415:
URL: https://github.com/apache/solr/pull/2415#discussion_r1583877903


##
dev-docs/releasing.adoc:
##
@@ -0,0 +1,73 @@
+
+= Releasing Solr
+:toc: left
+
+== Motivated?
+So you're of the opinion that there are unreleased features or bugfixes 
committed to the Solr repository that the world needs?
+Are you so convinced of this that you are willing to volunteer to make it 
happen?
+Good! This document tells you how to get started.
+
+== Overview
+The following is an overview of the artifacts you will be publishing. Although 
the release wizard should be your primary guide, having a picture of what's 
going on may help you understand and validate what the release wizard is asking 
you to do.
+
+There are four major parts of a release. They all become available to the 
public in slightly different ways, and it helps to understand these differences.
+
+IMPORTANT: All of these publications experience a time delay while background 
infrastructure detects and propagates your changes. There will be points in the 
release process when you just need to wait.
+
+=== Source Code and Binaries (downloads.apache.org)
+
+The distribution of a specific version of the source code is the theoretical 
center of any release by the Apache Software Foundation. As a convenience, 
precompiled binaries are also provided on downloads.apache.org. The mechanics 
of this process start with an SVN commit. The result of that commit is 
automatically synced to the downloads server (~5m?), and then on a longer time 
frame (6h?) anything on downloads is synced to archives.apache.org.
+
+=== Maven Artifacts (repository.apache.org)
+The compiled jar files, source jars, javadoc and pom need to be distributed to 
the maven ecosystem. This happens via repository.apache.org which is then 
automatically synced into maven central (~2h, upto 24h for maven central 
search). If you have released software to maven central via Sonatype, you will 
see that Apache uses the same repository manager software (Nexus), and this 
interface will look familiar to you.
+
+=== The Web Site (solr.apache.org)
+Our website must be updated with each release. It is based on the content of 
the solr-site git repository and checking in changes to the `main` branch there 
will automatically become available for preview within a few minutes at 
https://solr.staged.apache.org/[https://solr.staged.apache.org/]. Merging main 
into a branch named `production` publishes your updates to the live website 
also within a few minutes. Note that it is normal for the staging site links to 
javadocs and ref guide to return 404 because these are published by a different 
process.
+
+=== The Reference Guide (solr.apache.org/guide)
+The ref guide is published once every 24h by a Jenkins build found at 
https://ci-builds.apache.org/job/Solr/job/solr-reference-guide-official/[https://ci-builds.apache.org/job/Solr/job/solr-reference-guide-official/].
 This is a complicated process that has been automated for you. It is primarily 
influenced by the publication of an `antora.yaml` file during the steps the 
release wizard will guide you through. If the Jenkins build runs while there is 
a branch, but no updated antora.yaml file, an `M.N-beta` reference may be seen 
on the live ref guide, but there will be no `M.N-beta` ref guide pages and 
selecting it will merely browse the latest. After the Jenkins build runs, it 
takes several hours for the new version to become visible in a browser 
(possibly due to a caching layer?). There's a window of 6-30h after the release 
where this is not of concern, so don't panic. You can check the above jenkins 
job while you wait to estimate when the changes will be expected to become 
visible.
+
+== Step 0 - Become a Committer
+To do a release you must become a 
https://community.apache.org/contributors/becomingacommitter.html[committer] on 
the project. Additionally, if you are not on the 
https://apache.org/foundation/how-it-works/#pmc[Project Management Committee 
(PMC)]  you will also need to take special steps, and you will need to partner 
with a PMC member for at least one step. See 
https://www.apache.org/legal/release-policy.html#upload-ci
+
+== Step 1 - Run the Release Wizard!
+
+But wait! don't I need community approval?! (you exclaim)
+
+Yes! But there are some details to take care of that don't require anyone's 
approval, and getting comfortable with the release wizard will make it 
smoother, so you should run through the early sections of the release wizard 
first.
+
+=== Where to find the release wizard
+
+The release wizard is found in a checkout of solr at 
`dev-tools/scripts/releaseWizard.py`
+
+=== What working copy to use
+
+The release wizard is meant to be used from any working copy you like, with 
the expectation that you will check out the PARENT branch. In other words you 
should check out main to publish M.0.0 and branch_Mx to publish M.N.0, and 
branch M.N.x-1 for M.N.x. The 

Re: [PR] SOLR-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]

[via GitHub]

epugh commented on PR #2417:
URL: https://github.com/apache/solr/pull/2417#issuecomment-2083782067

   I think we should split the pure refactor out from the class loader stuff….
   
   On Mon, Apr 29, 2024 at 6:15 PM David Smiley ***@***.***>
   wrote:
   
   > ***@***. commented on this pull request.
   > --
   >
   > In solr/core/src/java/org/apache/solr/cli/SolrCLI.java
   > :
   >
   > > +
   > +  public static CloudHttp2SolrClient getCloudHttp2SolrClient(
   > +  String zkHost, Http2SolrClient.Builder builder) {
   > +return new 
CloudHttp2SolrClient.Builder(Collections.singletonList(zkHost), 
Optional.empty())
   > +.withSolrClassLoader(getSolrResourceLoader())
   > +.withInternalClientBuilder(builder)
   > +.build();
   > +  }
   > +
   > +  private static SolrResourceLoader getSolrResourceLoader() {
   > +String dir = System.getProperty("solr.solr.home");
   > +if (StrUtils.isNullOrEmpty(dir)) {
   > +  dir = System.getProperty("solr.install.dir");
   > +}
   > +final SolrResourceLoader loader = new 
SolrResourceLoader(Paths.get(dir));
   > +NodeConfig.initModules(loader, null);
   >
   > Come to think of it, maybe even for the CLI case we don't need a fancy
   > ClassLoader trick. Just call Thread.currentThread().setContextClassLoader()
   > super early in the ZkCLI and furthermore ensure SolrZkClient sets the
   > current classLoader in its constructor / field initializer.
   >
   > —
   > Reply to this email directly, view it on GitHub
   > , or
   > unsubscribe
   > 

   > .
   > You are receiving this because you were assigned.Message ID:
   > ***@***.***>
   >
   


-- 
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]

[via GitHub]

dsmiley commented on code in PR #2417:
URL: https://github.com/apache/solr/pull/2417#discussion_r1583843217


##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -607,6 +611,46 @@ public static String getZkHost(CommandLine cli) throws 
Exception {
 return zkHost;
   }
 
+  public static SolrZkClient getSolrZkClient(CommandLine cli) throws Exception 
{
+return getSolrZkClient(cli, getZkHost(cli));
+  }
+
+  public static SolrZkClient getSolrZkClient(CommandLine cli, String zkHost) 
throws Exception {
+if (zkHost == null) {
+  throw new IllegalStateException(
+  "Solr at "
+  + cli.getOptionValue("solrUrl")
+  + " is running in standalone server mode, this command can only 
be used when running in SolrCloud mode.\n");
+}
+return new SolrZkClient.Builder()
+.withUrl(zkHost)
+.withTimeout(SolrZkClientTimeout.DEFAULT_ZK_CLIENT_TIMEOUT, 
TimeUnit.MILLISECONDS)
+.withSolrClassLoader(getSolrResourceLoader())
+.build();
+  }
+
+  public static CloudHttp2SolrClient getCloudHttp2SolrClient(String zkHost) {
+return getCloudHttp2SolrClient(zkHost, null);
+  }
+
+  public static CloudHttp2SolrClient getCloudHttp2SolrClient(
+  String zkHost, Http2SolrClient.Builder builder) {
+return new CloudHttp2SolrClient.Builder(Collections.singletonList(zkHost), 
Optional.empty())
+.withSolrClassLoader(getSolrResourceLoader())
+.withInternalClientBuilder(builder)
+.build();
+  }
+
+  private static SolrResourceLoader getSolrResourceLoader() {
+String dir = System.getProperty("solr.solr.home");
+if (StrUtils.isNullOrEmpty(dir)) {
+  dir = System.getProperty("solr.install.dir");
+}
+final SolrResourceLoader loader = new SolrResourceLoader(Paths.get(dir));
+NodeConfig.initModules(loader, null);

Review Comment:
   Come to think of it, maybe even for the CLI case we don't need a fancy 
ClassLoader trick.  Just call Thread.currentThread().setContextClassLoader() 
super early in the ZkCLI and furthermore ensure SolrZkClient sets the current 
classLoader in its constructor / field initializer.



-- 
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]

[via GitHub]

laminelam commented on code in PR #2417:
URL: https://github.com/apache/solr/pull/2417#discussion_r1583820695


##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -607,6 +611,46 @@ public static String getZkHost(CommandLine cli) throws 
Exception {
 return zkHost;
   }
 
+  public static SolrZkClient getSolrZkClient(CommandLine cli) throws Exception 
{
+return getSolrZkClient(cli, getZkHost(cli));
+  }
+
+  public static SolrZkClient getSolrZkClient(CommandLine cli, String zkHost) 
throws Exception {
+if (zkHost == null) {
+  throw new IllegalStateException(
+  "Solr at "
+  + cli.getOptionValue("solrUrl")
+  + " is running in standalone server mode, this command can only 
be used when running in SolrCloud mode.\n");
+}
+return new SolrZkClient.Builder()
+.withUrl(zkHost)
+.withTimeout(SolrZkClientTimeout.DEFAULT_ZK_CLIENT_TIMEOUT, 
TimeUnit.MILLISECONDS)
+.withSolrClassLoader(getSolrResourceLoader())
+.build();
+  }
+
+  public static CloudHttp2SolrClient getCloudHttp2SolrClient(String zkHost) {
+return getCloudHttp2SolrClient(zkHost, null);
+  }
+
+  public static CloudHttp2SolrClient getCloudHttp2SolrClient(
+  String zkHost, Http2SolrClient.Builder builder) {
+return new CloudHttp2SolrClient.Builder(Collections.singletonList(zkHost), 
Optional.empty())
+.withSolrClassLoader(getSolrResourceLoader())
+.withInternalClientBuilder(builder)
+.build();
+  }
+
+  private static SolrResourceLoader getSolrResourceLoader() {
+String dir = System.getProperty("solr.solr.home");
+if (StrUtils.isNullOrEmpty(dir)) {
+  dir = System.getProperty("solr.install.dir");
+}
+final SolrResourceLoader loader = new SolrResourceLoader(Paths.get(dir));
+NodeConfig.initModules(loader, null);

Review Comment:
   @dsmiley 
   Firstable, I really appreciate the time you're spending on this, and your 
inputs are very valuable.
   
   I thought of adding a custom loader for CLI code but didn't want to 
duplicate the existing code. Actually I already did it 
[here](https://github.com/apache/solr/pull/826/commits/b3f4f830986042e8f194fa84088752f93b3abba8#diff-27c02533050bbfcb97de03a7d7e33588bb547f7b46f7e86e09c36175a5ef85c5)
 but end up abandoning it.
   
   Will get rid of SRL as far as this PR is concerned (for the CLI part).
   
   Still, I don't see how we can access _modules_ classes from the client side 
(**_solrj_**) without passing a SRL?
   



-- 
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]

[via GitHub]

laminelam commented on code in PR #2417:
URL: https://github.com/apache/solr/pull/2417#discussion_r1583820695


##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -607,6 +611,46 @@ public static String getZkHost(CommandLine cli) throws 
Exception {
 return zkHost;
   }
 
+  public static SolrZkClient getSolrZkClient(CommandLine cli) throws Exception 
{
+return getSolrZkClient(cli, getZkHost(cli));
+  }
+
+  public static SolrZkClient getSolrZkClient(CommandLine cli, String zkHost) 
throws Exception {
+if (zkHost == null) {
+  throw new IllegalStateException(
+  "Solr at "
+  + cli.getOptionValue("solrUrl")
+  + " is running in standalone server mode, this command can only 
be used when running in SolrCloud mode.\n");
+}
+return new SolrZkClient.Builder()
+.withUrl(zkHost)
+.withTimeout(SolrZkClientTimeout.DEFAULT_ZK_CLIENT_TIMEOUT, 
TimeUnit.MILLISECONDS)
+.withSolrClassLoader(getSolrResourceLoader())
+.build();
+  }
+
+  public static CloudHttp2SolrClient getCloudHttp2SolrClient(String zkHost) {
+return getCloudHttp2SolrClient(zkHost, null);
+  }
+
+  public static CloudHttp2SolrClient getCloudHttp2SolrClient(
+  String zkHost, Http2SolrClient.Builder builder) {
+return new CloudHttp2SolrClient.Builder(Collections.singletonList(zkHost), 
Optional.empty())
+.withSolrClassLoader(getSolrResourceLoader())
+.withInternalClientBuilder(builder)
+.build();
+  }
+
+  private static SolrResourceLoader getSolrResourceLoader() {
+String dir = System.getProperty("solr.solr.home");
+if (StrUtils.isNullOrEmpty(dir)) {
+  dir = System.getProperty("solr.install.dir");
+}
+final SolrResourceLoader loader = new SolrResourceLoader(Paths.get(dir));
+NodeConfig.initModules(loader, null);

Review Comment:
   @dsmiley 
   Firstable, I really appreciate the time you're spending on this, and your 
inputs are very valuable.
   
   I thought of adding a custom loader for CLI code but didn't want to 
duplicate the existing code. Actually I already did it 
[here](https://github.com/apache/solr/pull/826/commits/b3f4f830986042e8f194fa84088752f93b3abba8#diff-27c02533050bbfcb97de03a7d7e33588bb547f7b46f7e86e09c36175a5ef85c5)
 but end up abandoning it.
   
   Will get rid of SRL as far as this PR is concerned (for the CLI part).
   
   Still, I don't see how we can access _modules_ classes from the client side 
(**_solrj_**) without passing a SRL?
   



-- 
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]

[via GitHub]

laminelam commented on code in PR #2417:
URL: https://github.com/apache/solr/pull/2417#discussion_r1583820695


##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -607,6 +611,46 @@ public static String getZkHost(CommandLine cli) throws 
Exception {
 return zkHost;
   }
 
+  public static SolrZkClient getSolrZkClient(CommandLine cli) throws Exception 
{
+return getSolrZkClient(cli, getZkHost(cli));
+  }
+
+  public static SolrZkClient getSolrZkClient(CommandLine cli, String zkHost) 
throws Exception {
+if (zkHost == null) {
+  throw new IllegalStateException(
+  "Solr at "
+  + cli.getOptionValue("solrUrl")
+  + " is running in standalone server mode, this command can only 
be used when running in SolrCloud mode.\n");
+}
+return new SolrZkClient.Builder()
+.withUrl(zkHost)
+.withTimeout(SolrZkClientTimeout.DEFAULT_ZK_CLIENT_TIMEOUT, 
TimeUnit.MILLISECONDS)
+.withSolrClassLoader(getSolrResourceLoader())
+.build();
+  }
+
+  public static CloudHttp2SolrClient getCloudHttp2SolrClient(String zkHost) {
+return getCloudHttp2SolrClient(zkHost, null);
+  }
+
+  public static CloudHttp2SolrClient getCloudHttp2SolrClient(
+  String zkHost, Http2SolrClient.Builder builder) {
+return new CloudHttp2SolrClient.Builder(Collections.singletonList(zkHost), 
Optional.empty())
+.withSolrClassLoader(getSolrResourceLoader())
+.withInternalClientBuilder(builder)
+.build();
+  }
+
+  private static SolrResourceLoader getSolrResourceLoader() {
+String dir = System.getProperty("solr.solr.home");
+if (StrUtils.isNullOrEmpty(dir)) {
+  dir = System.getProperty("solr.install.dir");
+}
+final SolrResourceLoader loader = new SolrResourceLoader(Paths.get(dir));
+NodeConfig.initModules(loader, null);

Review Comment:
   @dsmiley 
   Firstable, I really appreciate the time you're spending on this, and your 
inputs are very valuable.
   
   I thought of adding a custom loader for CLI code but didn't want to 
duplicate the existing code. Actually I already did it 
[here](https://github.com/apache/solr/pull/826/commits/b3f4f830986042e8f194fa84088752f93b3abba8#diff-27c02533050bbfcb97de03a7d7e33588bb547f7b46f7e86e09c36175a5ef85c5)
 but end up abandoning it.
   
   Will get rid of SRL as far as this PR is concerned (for the CLI part).
   
   Still, I don't see how we can access _modules_ classes from the client side 
( **_solrj_**) without passing a SRL?
   



-- 
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]

[via GitHub]

laminelam commented on code in PR #2417:
URL: https://github.com/apache/solr/pull/2417#discussion_r1583820695


##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -607,6 +611,46 @@ public static String getZkHost(CommandLine cli) throws 
Exception {
 return zkHost;
   }
 
+  public static SolrZkClient getSolrZkClient(CommandLine cli) throws Exception 
{
+return getSolrZkClient(cli, getZkHost(cli));
+  }
+
+  public static SolrZkClient getSolrZkClient(CommandLine cli, String zkHost) 
throws Exception {
+if (zkHost == null) {
+  throw new IllegalStateException(
+  "Solr at "
+  + cli.getOptionValue("solrUrl")
+  + " is running in standalone server mode, this command can only 
be used when running in SolrCloud mode.\n");
+}
+return new SolrZkClient.Builder()
+.withUrl(zkHost)
+.withTimeout(SolrZkClientTimeout.DEFAULT_ZK_CLIENT_TIMEOUT, 
TimeUnit.MILLISECONDS)
+.withSolrClassLoader(getSolrResourceLoader())
+.build();
+  }
+
+  public static CloudHttp2SolrClient getCloudHttp2SolrClient(String zkHost) {
+return getCloudHttp2SolrClient(zkHost, null);
+  }
+
+  public static CloudHttp2SolrClient getCloudHttp2SolrClient(
+  String zkHost, Http2SolrClient.Builder builder) {
+return new CloudHttp2SolrClient.Builder(Collections.singletonList(zkHost), 
Optional.empty())
+.withSolrClassLoader(getSolrResourceLoader())
+.withInternalClientBuilder(builder)
+.build();
+  }
+
+  private static SolrResourceLoader getSolrResourceLoader() {
+String dir = System.getProperty("solr.solr.home");
+if (StrUtils.isNullOrEmpty(dir)) {
+  dir = System.getProperty("solr.install.dir");
+}
+final SolrResourceLoader loader = new SolrResourceLoader(Paths.get(dir));
+NodeConfig.initModules(loader, null);

Review Comment:
   @dsmiley 
   Firstable, I really appreciate the time you're spending on this, and your 
inputs are very valuable.
   
   I thought of adding a custom loader for CLI code but didn't want to 
duplicate the existing code. Actually I already did it 
[here](https://github.com/apache/solr/pull/826/commits/b3f4f830986042e8f194fa84088752f93b3abba8#diff-27c02533050bbfcb97de03a7d7e33588bb547f7b46f7e86e09c36175a5ef85c5)
 but end up abandoning it.
   
   Will get rid of SRL as far as this PR is concerned (for the CLI part).
   
   Still, I don't see how we can access _modules_ classes from **_solrj_** 
without passing a SRL?
   



-- 
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-14115: Remove deprecated zkcli script. [solr]

[via GitHub]

epugh commented on PR #2427:
URL: https://github.com/apache/solr/pull/2427#issuecomment-2083664163

   Waiting on https://github.com/apache/solr/pull/2428 to be completed first...


-- 
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-12813: subqueries should respect basic auth [solr]

[via GitHub]

rseitz commented on PR #2404:
URL: https://github.com/apache/solr/pull/2404#issuecomment-2083646456

   I opened a separate PR here: https://github.com/apache/solr/pull/2429
   Basically, it's a one-line change that updates another 
`_parser.buildRequestFrom()` call inside `EmbeddedSolrServer.request()`.  This 
other call doesn't seem to be involved in the subquery execution codepath, so 
it didn't need to be updated for fixing SOLR-12813. In earlier discussion we 
had here, folks asked if there were other cases we might be missing where a 
Principal is lost, so I did some more looking around. This is the other such 
case that I've come across so far. I added some more description on the new 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-16577) Core load issues are not always logged

[David Smiley (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842156#comment-17842156
 ] 

David Smiley commented on SOLR-16577:
-

What a surprise that is; sorry to hear that!  I think upping the timeout (e.g. 
to infinity) for this scenario makes the most sense to me.  I still don't 
believe in the needless use of a Future here.

> Core load issues are not always logged
> --
>
> Key: SOLR-16577
> URL: https://issues.apache.org/jira/browse/SOLR-16577
> Project: Solr
>  Issue Type: Improvement
>Reporter: Haythem Khiri
>Assignee: David Smiley
>Priority: Minor
> Fix For: 9.5
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> It's possible for a core load failure to not have its cause logged. At least 
> the failure is tracked in a metric and one can do an admin request to fetch 
> the cause but really it ought to be logged so one can more easily see what 
> the problem is.



--
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-12813 followup -- preserve user Principal in alternate codepath in EmbeddedSolrServer [solr]

[via GitHub]

rseitz commented on PR #2429:
URL: https://github.com/apache/solr/pull/2429#issuecomment-2083640463

   Tagging @epugh and @dsmiley   


-- 
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] SOLR-12813 followup -- preserve user Principal in alternate codepath in EmbeddedSolrServer [solr]

[via GitHub]

rseitz opened a new pull request, #2429:
URL: https://github.com/apache/solr/pull/2429

   https://issues.apache.org/jira/browse/SOLR-12813
   
   # Description
   
   This is a followup to a previous 
[PR](https://github.com/apache/solr/pull/2404) that fixed SOLR-12813. 
   
   This current change is intended as proactive code cleanup and is not needed 
for resolving the issue described in SOLR-12813, which was fully resolved by 
the previous PR.
   
   EmbeddedSolrServer#request() has two separate places where the 
_parser.buildRequestFrom() utility method is called. 
   
   The first codepath is active when the 
`coreContainer.getRequestHandler(path)` returns non-null, which is to say that 
we're able to retrieve the designated SolrRequestHandler by looking it up on 
the available CoreContainer. 
   
   The second codepath is active when `coreContainer.getRequestHandler(path)` 
return null and instead we need to retrieve the SolrCore from the CoreContainer 
and get the SolrRequestHandler from that SolrCore. This second codepath is the 
one that's used in subquery execution. It was updated in the initial fix for 
SOLR-12813 so that the call to _parser.buildRequestFrom() would now include the 
user Principal. 
   
   However, the first codepath was left alone because it was not found to be 
involved in subquery execution. In the present PR, the first codepath is being 
updated as well, in the interest of keeping the logic as consistent as possible 
across the two codepaths in EmbeddedSolrServer.request()
   
   # Solution
   
   N/A
   
   # Tests
   
   I am looking for advice on how to create a test for this change. I believe 
this change is non-intrusive and safe: when we pass the Principal, it will 
either be null, in which case the code will act the same as before -- or it 
will be non-null, in which case we _should_ be passing it. However, it appears 
that none of the existing unit tests "care" about this change, so it would be 
good to create a test that targets it. I found some tests which invoke the 
codepath in EmbededSolrServer.request that we're modifying here, for example 
TestEmbeddedSolrServerAdminHandler, but they are local SolrTestCaseJ4 instances 
and I believe we need a SolrCloudTestCase to be able to set up security.json in 
zookeeper to create a meaningful test... or maybe there's an easier way? If 
anyone has insight on when/why one codepath would be active instead of the 
other -- that's to way, why a request handler would be found on the 
CoreContainer versus only on the SolrCore, I'm interested to know the 
background.
   
   
   # 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)
   - [x] I have developed this patch against the `main` branch.
   - [x] 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-16796: introduce org.cyclonedx.bom gradle plugin [solr]

[via GitHub]

janhoy commented on PR #1203:
URL: https://github.com/apache/solr/pull/1203#issuecomment-2083639846

   I'm positive to including this as a first step and then proceeding with 
publishing SBOM as a release artifact as proposed.


-- 
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-16577) Core load issues are not always logged

[Houston Putman (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842151#comment-17842151
 ] 

Houston Putman commented on SOLR-16577:
---

[~dsmiley] I'm pretty sure we ran into issues upgrading to 9.5 that stem from 
this PR.

The loading of cores asynchonously was simplified to remove the use of Futures 
to wait for the cores to be loaded. Instead, 
{{ExecutorUtil.shutdownAndAwaitTermination(coreLoadExecutor)}} was used to let 
the core loading start and complete.

Unfortunately for us, {{ExecutorUtil.shutdownAndAwaitTermination(executor)}} 
defaults to a timeout of 60 seconds. This means that if your cores don't load 
in 60 seconds, then you will have problems. Notably, it will send interrupts to 
the coreLoading threads which will make it look like some of your configSet 
files cannot be found in ZK (which is quite an annoying red herring).

We should either up this timeout value (should it really even timeout?) or 
return to using the methods that use "Future"s.

 

> Core load issues are not always logged
> --
>
> Key: SOLR-16577
> URL: https://issues.apache.org/jira/browse/SOLR-16577
> Project: Solr
>  Issue Type: Improvement
>Reporter: Haythem Khiri
>Assignee: David Smiley
>Priority: Minor
> Fix For: 9.5
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> It's possible for a core load failure to not have its cause logged. At least 
> the failure is tracked in a metric and one can do an admin request to fetch 
> the cause but really it ought to be logged so one can more easily see what 
> the problem is.



--
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-16577) Core load issues are not always logged

[Houston Putman (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Houston Putman reassigned SOLR-16577:
-

Assignee: David Smiley

> Core load issues are not always logged
> --
>
> Key: SOLR-16577
> URL: https://issues.apache.org/jira/browse/SOLR-16577
> Project: Solr
>  Issue Type: Improvement
>Reporter: Haythem Khiri
>Assignee: David Smiley
>Priority: Minor
> Fix For: 9.5
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> It's possible for a core load failure to not have its cause logged. At least 
> the failure is tracked in a metric and one can do an admin request to fetch 
> the cause but really it ought to be logged so one can more easily see what 
> the problem is.



--
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] Support running embedded-zk in "ensemble" mode [solr]

[via GitHub]

janhoy commented on PR #2391:
URL: https://github.com/apache/solr/pull/2391#issuecomment-2083599034

   Great work. I think we should rip out the existing embedded ZK, which is a 
hack.
   
   Do you want to proceed in a PR or perhaps in a central feature branch?


-- 
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]

[via GitHub]

dsmiley commented on code in PR #2417:
URL: https://github.com/apache/solr/pull/2417#discussion_r1583658873


##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -607,6 +611,46 @@ public static String getZkHost(CommandLine cli) throws 
Exception {
 return zkHost;
   }
 
+  public static SolrZkClient getSolrZkClient(CommandLine cli) throws Exception 
{
+return getSolrZkClient(cli, getZkHost(cli));
+  }
+
+  public static SolrZkClient getSolrZkClient(CommandLine cli, String zkHost) 
throws Exception {
+if (zkHost == null) {
+  throw new IllegalStateException(
+  "Solr at "
+  + cli.getOptionValue("solrUrl")
+  + " is running in standalone server mode, this command can only 
be used when running in SolrCloud mode.\n");
+}
+return new SolrZkClient.Builder()
+.withUrl(zkHost)
+.withTimeout(SolrZkClientTimeout.DEFAULT_ZK_CLIENT_TIMEOUT, 
TimeUnit.MILLISECONDS)
+.withSolrClassLoader(getSolrResourceLoader())
+.build();
+  }
+
+  public static CloudHttp2SolrClient getCloudHttp2SolrClient(String zkHost) {
+return getCloudHttp2SolrClient(zkHost, null);
+  }
+
+  public static CloudHttp2SolrClient getCloudHttp2SolrClient(
+  String zkHost, Http2SolrClient.Builder builder) {
+return new CloudHttp2SolrClient.Builder(Collections.singletonList(zkHost), 
Optional.empty())
+.withSolrClassLoader(getSolrResourceLoader())
+.withInternalClientBuilder(builder)
+.build();
+  }
+
+  private static SolrResourceLoader getSolrResourceLoader() {
+String dir = System.getProperty("solr.solr.home");
+if (StrUtils.isNullOrEmpty(dir)) {
+  dir = System.getProperty("solr.install.dir");
+}
+final SolrResourceLoader loader = new SolrResourceLoader(Paths.get(dir));
+NodeConfig.initModules(loader, null);

Review Comment:
   I appreciate it's frustrating given you've consulted with others already.  
It's awkward for me because here I am commenting on this PR and the other 
committers you speak of are not "here" and that it was one or two years ago, 
and the scope is confusing (just CLI or also must address server).  Hey 
@gerlowskija you're one of them.  My concern is adding ClassLoader setters in 
places that feel out-of-place, especially CloudSolrClient classes which we 
should highly scrutinize.
   
   This PR is just for client CLI tools.  Couldn't the CLI create a 
ClassLoader, add the module JARs, and then go load CLI tool with this loader 
that can in do whatever?
   
   Server:  Ideally the server should only instantiate one CloudSolrClient for 
the current cluster, and when it does so it can provide its own ZkStateReader, 
which we can assume already has the proper SolrZkClient loaded with the right 
class path.  The Thread.currentThread().getContextClassLoader() can be used to 
initialize the classLoader field in SolrZkClient.  CoreContainer will set the 
Thread ContextClassLoader when it calls load().



-- 
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]

[via GitHub]

dsmiley commented on code in PR #2417:
URL: https://github.com/apache/solr/pull/2417#discussion_r1583620967


##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudLegacySolrClient.java:
##
@@ -379,7 +387,7 @@ public CloudLegacySolrClient build() {
   "Both zkHost(s) & solrUrl(s) have been specified. Only specify 
one.");
 } else if (!zkHosts.isEmpty()) {
   this.stateProvider =
-  ClusterStateProvider.newZkClusterStateProvider(zkHosts, 
zkChroot, canUseZkACLs);
+  ClusterStateProvider.newZkClusterStateProvider(zkHosts, 
zkChroot, canUseZkACLs, solrClassLoader);

Review Comment:
   Sorry, I had that confused a bit; never mind.



-- 
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] Shard split supports encryption. [solr-sandbox]

[via GitHub]

dsmiley commented on PR #103:
URL: https://github.com/apache/solr-sandbox/pull/103#issuecomment-2083458789

   1. communicate (in the description) what this is about.
   2. two day standard waiting period before merge.   Another's +1 may 
accelerate this.


-- 
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]

[via GitHub]

laminelam commented on code in PR #2417:
URL: https://github.com/apache/solr/pull/2417#discussion_r1583499845


##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudLegacySolrClient.java:
##
@@ -379,7 +387,7 @@ public CloudLegacySolrClient build() {
   "Both zkHost(s) & solrUrl(s) have been specified. Only specify 
one.");
 } else if (!zkHosts.isEmpty()) {
   this.stateProvider =
-  ClusterStateProvider.newZkClusterStateProvider(zkHosts, 
zkChroot, canUseZkACLs);
+  ClusterStateProvider.newZkClusterStateProvider(zkHosts, 
zkChroot, canUseZkACLs, solrClassLoader);

Review Comment:
   I am not really sure to understand why did you mean here.
   _ZkStateReader_ to call _newZkClusterStateProvider_ method?
   Wouldn't this end up in a recursive call?
   
   BTW, _ZkStateReader_ doesn't have access to _SolrRecourceLoader_ neither 
(runs under solrj*).



-- 
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]

[via GitHub]

laminelam commented on code in PR #2417:
URL: https://github.com/apache/solr/pull/2417#discussion_r1583497184


##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -607,6 +611,46 @@ public static String getZkHost(CommandLine cli) throws 
Exception {
 return zkHost;
   }
 
+  public static SolrZkClient getSolrZkClient(CommandLine cli) throws Exception 
{
+return getSolrZkClient(cli, getZkHost(cli));
+  }
+
+  public static SolrZkClient getSolrZkClient(CommandLine cli, String zkHost) 
throws Exception {
+if (zkHost == null) {
+  throw new IllegalStateException(
+  "Solr at "
+  + cli.getOptionValue("solrUrl")
+  + " is running in standalone server mode, this command can only 
be used when running in SolrCloud mode.\n");
+}
+return new SolrZkClient.Builder()
+.withUrl(zkHost)
+.withTimeout(SolrZkClientTimeout.DEFAULT_ZK_CLIENT_TIMEOUT, 
TimeUnit.MILLISECONDS)
+.withSolrClassLoader(getSolrResourceLoader())
+.build();
+  }
+
+  public static CloudHttp2SolrClient getCloudHttp2SolrClient(String zkHost) {
+return getCloudHttp2SolrClient(zkHost, null);
+  }
+
+  public static CloudHttp2SolrClient getCloudHttp2SolrClient(
+  String zkHost, Http2SolrClient.Builder builder) {
+return new CloudHttp2SolrClient.Builder(Collections.singletonList(zkHost), 
Optional.empty())
+.withSolrClassLoader(getSolrResourceLoader())
+.withInternalClientBuilder(builder)
+.build();
+  }
+
+  private static SolrResourceLoader getSolrResourceLoader() {
+String dir = System.getProperty("solr.solr.home");
+if (StrUtils.isNullOrEmpty(dir)) {
+  dir = System.getProperty("solr.install.dir");
+}
+final SolrResourceLoader loader = new SolrResourceLoader(Paths.get(dir));
+NodeConfig.initModules(loader, null);

Review Comment:
   I completely agree that this PR is little bit broader than the JIRA. Will 
split it, or change this one to get rid of the SolrResourceLoader stuff. But we 
still need a solution on the _SolrResourceLoader_ issue.
   
   @dsmiley re.   _SolrResourceLoader_
   I know the solution is not perfect. I have discussed the issue with 4 other 
committers, this is the best solution we would come up will (adding a way to 
pass SRL to SolrZKClient).
   
   
   



-- 
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-14115: Update the docs to reference to the bin/solr equivalent of the zkcli.sh [solr]

[via GitHub]

epugh commented on PR #2428:
URL: https://github.com/apache/solr/pull/2428#issuecomment-2083134993

   I plan on backporting this to `branch_9x`.   


-- 
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] SOLR-14115: Update the docs to reference to the bin/solr equivalent of the zkcli.sh [solr]

[via GitHub]

epugh opened a new pull request, #2428:
URL: https://github.com/apache/solr/pull/2428

   https://issues.apache.org/jira/browse/SOLR-14115
   
   
   # Description
   
   Update the Ref Guide to not refer to zkcli.sh
   
   # Solution
   
   I did the lightest version of updating the Ref Guide to refer to the 
bin/solr equivalent of zkcli.sh.  
   
I didn't try to rethink the layout of the Ref Guide... However, if feels 
like the `solr-control-script-reference.adoc` page is getting overwhelmed   
 We probably should break up that page into control script, zk commands, other 
features.Therefore, instead of eliminating `zookeeper-utilities.adoc`, I 
left it, because in the future we could move more documentation specific to zk 
into this page FROM `solr-control-script-reference.adoc`.  
   
   Also didn't want to think about how to handle deleting a ref guide page!
   
   # Tests
   
   Manual testing.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [ ] 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.
   - [ ] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] 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)
   - [ ] 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

[jira] [Commented] (SOLR-17244) Create a dev-doc to orient prospective release managers

[Gus Heck (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-17244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842054#comment-17842054
 ] 

Gus Heck commented on SOLR-17244:
-

So I just pushed the last changes I want to add, but I'd be happy for folks to 
verify accuracy of what I've said, and of course proof reading is also welcome. 
Will merge tonight if no changes are needed (or suggested changes are 
small/simple).

> Create a dev-doc to orient prospective release managers
> ---
>
> Key: SOLR-17244
> URL: https://issues.apache.org/jira/browse/SOLR-17244
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We have an extensively developed releaseWizard script, but there are a number 
> of assumptions it makes that won't be clear to first time users. (like the 
> idea that they are actually expected to run it long before actually releasing 
> anything!). So to ease the "getting started" for new release managers we 
> should have an orientation doc that lets them know when, where and how to get 
> started with the releaseWizard.



--
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] Shard split supports encryption. [solr-sandbox]

[via GitHub]

anshumg commented on PR #103:
URL: https://github.com/apache/solr-sandbox/pull/103#issuecomment-2083098182

   @dsmiley  - that wasn't the intent, but I see that it was a one off. I guess 
everyone is on the same page :) Let's respect this repository almost as much as 
the main one so it's easier for others to collaborate and follow.


-- 
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-12813: subqueries should respect basic auth [solr]

[via GitHub]

epugh commented on PR #2404:
URL: https://github.com/apache/solr/pull/2404#issuecomment-2082948170

   I think open a seperate PR, just to keep the one that was merged and 
committed seperate from a new one.  I'd love to see the suggested PR...   Do we 
also need a test there?


-- 
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-12813: subqueries should respect basic auth [solr]

[via GitHub]

rseitz commented on PR #2404:
URL: https://github.com/apache/solr/pull/2404#issuecomment-2082885569

   Thanks @epugh and @dsmiley for the feedback and support for this fix. I'll 
open a separate ticket for the security.json refactor and tag Eric.
   
   There is a minor followup I would like to add here: 
`EmbeddedSolrServer.request()` has _two_ places where 
`_parser.buildRequestFrom()` is called. One codepath is when the request 
handler can be found on the CoreContainer, and the other codepath is when the 
request handler has to be retrieved from the SolrCore itself. This PR so far 
only updated the second codepath because that's the path that's active in the 
subquery execution scenario. To be consistent though, I'm thinking the first 
codepath should be updated as well. It's a one-line change just to add the 
Principal to a _parser.buildRequestFrom(). I'm planning to submit to this same 
branch shortly. Since existing unit tests don't seem to care about this, I'd be 
interested in any advice on if & how we should add coverage for 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-16833: Add blog to Solr website [solr-site]

[via GitHub]

gerlowskija merged PR #97:
URL: https://github.com/apache/solr-site/pull/97


-- 
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-4587: integrate lucene-monitor into solr [solr]

[via GitHub]

kotman12 commented on PR #2382:
URL: https://github.com/apache/solr/pull/2382#issuecomment-2082729041

   @cpoerschke I was reading your last comment more carefully and I want to 
stress that the presearcher, once constructed, should be completely _stateless_ 
in the current proposal. The whole point of extracting the internal bits of 
lucene-monitor was to avoid its cumbersome internal state management that 
doesn't really fit nicely into solr (at least with anything I've been able to 
come up with). The presearcher merely exposes the methods to _efficiently_ 
convert queries into documents (and vice versa) which make reverse search 
faster. That is why it is used by both `MonitorUpdateRequestProcessor` and 
`ReverseQueryParser`.


-- 
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] Parses CHANGES.txt to identify contributors [solr]

[via GitHub]

dsmiley commented on code in PR #2424:
URL: https://github.com/apache/solr/pull/2424#discussion_r1583066046


##
dev-tools/scripts/parseContributorsFromChanges.py:
##
@@ -0,0 +1,63 @@
+#  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.
+
+import sys
+import re
+from collections import defaultdict
+
+# Read data from standard input
+data = sys.stdin.read()
+
+# Replace all carriage return line feed (Windows) with line feed
+data = data.replace('\r\n', '\n')
+
+# Replace all carriage return (Mac OS before X) with line feed
+data = data.replace('\r', '\n')
+
+# Split data at blank lines
+paras = data.split('\n\n')
+
+# Initialize a default dictionary to store contributors and their counts
+contributors = defaultdict(int)
+
+# Regular expression to find the attribution in parentheses at the end of a 
line
+pattern = re.compile(r"\(([^()]*)\)$")
+
+for para in paras:
+  # Normalize whitespace (replace all whitespace with a single space)
+  para = re.sub('\s+', ' ', para).strip()
+  #print(f'> {para}')
+
+  # Find all contributors in the line
+  match = pattern.search(para.strip())
+  if match:
+attribution = match.group(1)
+# might have a "via" committer; we only want the author here
+attribution = attribution.split(" via ")[0] # keep left side
+# Split the contributors by comma and strip whitespace
+for contributor in attribution.split(','):
+  contributor = contributor.strip()
+  contributors[contributor] += 1
+
+del contributors['solrbot']
+
+sorted_contributors = sorted(contributors.items(), key=lambda item: item[1], 
reverse=True)

Review Comment:
   A smaller font would be nice... kind of like credits so as to not distract 
from the primary message of what the release is.  Maybe centered.



-- 
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]

[via GitHub]

dsmiley commented on code in PR #2417:
URL: https://github.com/apache/solr/pull/2417#discussion_r1583046307


##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudLegacySolrClient.java:
##
@@ -379,7 +387,7 @@ public CloudLegacySolrClient build() {
   "Both zkHost(s) & solrUrl(s) have been specified. Only specify 
one.");
 } else if (!zkHosts.isEmpty()) {
   this.stateProvider =
-  ClusterStateProvider.newZkClusterStateProvider(zkHosts, 
zkChroot, canUseZkACLs);
+  ClusterStateProvider.newZkClusterStateProvider(zkHosts, 
zkChroot, canUseZkACLs, solrClassLoader);

Review Comment:
   We're adding a SolrClassLoader just for this?  Instead, ZkStateReader can 
instantiate this newZkClusterStateProvider itself (with the right class loader).



-- 
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] SOLR-14115: Remove deprecated zkcli script. [solr]

[via GitHub]

epugh opened a new pull request, #2427:
URL: https://github.com/apache/solr/pull/2427

   https://issues.apache.org/jira/browse/SOLR-14115
   
   # Description
   
   Removing zkcli.sh from `main`
   
   # Solution
   
   We have left zkcli.sh in the `branch_9x` of Solr to not create too much 
change, however in 10 we want to reduce our complexity in our cli's, so lets 
remove it.  
   
   # Tests
   n/a
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [ ] 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.
   - [ ] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] 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)
   - [ ] 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

[jira] [Resolved] (SOLR-14115) Deprecate zkcli.sh

[Eric Pugh (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Pugh resolved SOLR-14115.
--
Fix Version/s: 9.7
   Resolution: Fixed

> Deprecate zkcli.sh
> --
>
> Key: SOLR-14115
> URL: https://issues.apache.org/jira/browse/SOLR-14115
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Reporter: Erick Erickson
>Assignee: Eric Pugh
>Priority: Major
> Fix For: 9.7
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> I think it's a valid argument that these have outlived their usefulness and 
> we should remove them and have APIs to do what Solr requires. Especially if 
> we can find and point to a third-party visual ZK tool for _changing_ 
> arbitrary data in ZK. Zookeeper 3.5.5 has the admin server which has a UI 
> (although I don't see how to change data in ZK with it. Haven't looked very 
> much).
> While we're ripping stuff out of Solr, are these candidates? It would break 
> my heart to rip ZK support out from bin/solr, but all good things must come 
> to an end. Why do we maintain three (zkcli, bin/solr and the APIs) ways of 
> doing the same thing?
> Mark put the zkcli stuff in before we had APIs to do what Solr needs to do 
> with ZK, mainly uploading configsets at the time. I put the zk support in 
> bin/solr also before the APIs existed because I thought having to learn our 
> custom wrapper for ZK was yet another orphan bit of code laying around. All 
> before we had things like the configsets API.
> Personally, I'd prefer removing zkcli rather than bin/solr, but that's 
> because I originated the bin/solr code ;)
> This occurred when reading SOLR-14109, I'm not entirely sure what I _really_ 
> think about it.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

[jira] [Commented] (SOLR-14115) Deprecate zkcli.sh

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841966#comment-17841966
 ] 

ASF subversion and git services commented on SOLR-14115:


Commit b93083e4ccbb0fb41657c85a1fff8925052a3d24 in solr's branch 
refs/heads/branch_9x from Eric Pugh
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=b93083e4ccb ]

SOLR-14115: Allow bin/solr zk commands to have parity with zkcli.sh commands. 
(#2298)

Add updateacls, cluster, and linkconfig as standard Solr tools.  Introduce some 
better testing of these relatively unknown tools.   Keep zkcli.sh as is for the 
9x branch of code.   Some challenges around how we handle compression of 
state.json dealt with.


> Deprecate zkcli.sh
> --
>
> Key: SOLR-14115
> URL: https://issues.apache.org/jira/browse/SOLR-14115
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Reporter: Erick Erickson
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> I think it's a valid argument that these have outlived their usefulness and 
> we should remove them and have APIs to do what Solr requires. Especially if 
> we can find and point to a third-party visual ZK tool for _changing_ 
> arbitrary data in ZK. Zookeeper 3.5.5 has the admin server which has a UI 
> (although I don't see how to change data in ZK with it. Haven't looked very 
> much).
> While we're ripping stuff out of Solr, are these candidates? It would break 
> my heart to rip ZK support out from bin/solr, but all good things must come 
> to an end. Why do we maintain three (zkcli, bin/solr and the APIs) ways of 
> doing the same thing?
> Mark put the zkcli stuff in before we had APIs to do what Solr needs to do 
> with ZK, mainly uploading configsets at the time. I put the zk support in 
> bin/solr also before the APIs existed because I thought having to learn our 
> custom wrapper for ZK was yet another orphan bit of code laying around. All 
> before we had things like the configsets API.
> Personally, I'd prefer removing zkcli rather than bin/solr, but that's 
> because I originated the bin/solr code ;)
> This occurred when reading SOLR-14109, I'm not entirely sure what I _really_ 
> think about it.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Re: [PR] SOLR-14115: Allow bin/solr zk commands to have parity with zkcli.sh commands. [solr]

[via GitHub]

epugh merged PR #2298:
URL: https://github.com/apache/solr/pull/2298


-- 
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-14115) Deprecate zkcli.sh

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841963#comment-17841963
 ] 

ASF subversion and git services commented on SOLR-14115:


Commit 963b62983a9802789676903eeb6ac928c2d9b5aa in solr's branch 
refs/heads/main from Eric Pugh
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=963b62983a9 ]

SOLR-14115: Allow bin/solr zk commands to have parity with zkcli.sh commands. 
(#2298)

Add updateacls, cluster, and linkconfig as standard Solr tools.  Introduce some 
better testing of these relatively unknown tools.   Keep zkcli.sh as is for the 
9x branch of code.   Some challenges around how we handle compression of 
state.json dealt with.

> Deprecate zkcli.sh
> --
>
> Key: SOLR-14115
> URL: https://issues.apache.org/jira/browse/SOLR-14115
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Reporter: Erick Erickson
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> I think it's a valid argument that these have outlived their usefulness and 
> we should remove them and have APIs to do what Solr requires. Especially if 
> we can find and point to a third-party visual ZK tool for _changing_ 
> arbitrary data in ZK. Zookeeper 3.5.5 has the admin server which has a UI 
> (although I don't see how to change data in ZK with it. Haven't looked very 
> much).
> While we're ripping stuff out of Solr, are these candidates? It would break 
> my heart to rip ZK support out from bin/solr, but all good things must come 
> to an end. Why do we maintain three (zkcli, bin/solr and the APIs) ways of 
> doing the same thing?
> Mark put the zkcli stuff in before we had APIs to do what Solr needs to do 
> with ZK, mainly uploading configsets at the time. I put the zk support in 
> bin/solr also before the APIs existed because I thought having to learn our 
> custom wrapper for ZK was yet another orphan bit of code laying around. All 
> before we had things like the configsets API.
> Personally, I'd prefer removing zkcli rather than bin/solr, but that's 
> because I originated the bin/solr code ;)
> This occurred when reading SOLR-14109, I'm not entirely sure what I _really_ 
> think about it.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

[jira] [Resolved] (SOLR-16921) Use -solrUrl to derive the zk host connection for bin/solr zk subcommands

[Eric Pugh (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-16921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Pugh resolved SOLR-16921.
--
Fix Version/s: 9.7
   Resolution: Fixed

> Use -solrUrl to derive the zk host connection for bin/solr zk subcommands
> -
>
> Key: SOLR-16921
> URL: https://issues.apache.org/jira/browse/SOLR-16921
> Project: Solr
>  Issue Type: Sub-task
>  Components: cli
>Affects Versions: main (10.0), 9.3
>Reporter: Eric Pugh
>Assignee: Eric Pugh
>Priority: Minor
> Fix For: 9.7
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We have a message like:
>  if (zkHost == null) {
>   throw new IllegalStateException(
>   "Solr at "
>   + cli.getOptionValue("solrUrl")
>   + " is running in standalone server mode, upconfig can only be 
> used when running in SolrCloud mode.\n");
> }
> but we don't declare the option value of solrUrl..  
> Although, why not???



--
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-16921) Use -solrUrl to derive the zk host connection for bin/solr zk subcommands

[Eric Pugh (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-16921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Pugh updated SOLR-16921:
-
Summary: Use -solrUrl to derive the zk host connection for bin/solr zk 
subcommands  (was: bin/solr upconfig and downconfig reference solrUrl but don't 
list it as option!)

> Use -solrUrl to derive the zk host connection for bin/solr zk subcommands
> -
>
> Key: SOLR-16921
> URL: https://issues.apache.org/jira/browse/SOLR-16921
> Project: Solr
>  Issue Type: Sub-task
>  Components: cli
>Affects Versions: main (10.0), 9.3
>Reporter: Eric Pugh
>Assignee: Eric Pugh
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We have a message like:
>  if (zkHost == null) {
>   throw new IllegalStateException(
>   "Solr at "
>   + cli.getOptionValue("solrUrl")
>   + " is running in standalone server mode, upconfig can only be 
> used when running in SolrCloud mode.\n");
> }
> but we don't declare the option value of solrUrl..  
> Although, why not???



--
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-16921) bin/solr upconfig and downconfig reference solrUrl but don't list it as option!

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-16921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841947#comment-17841947
 ] 

ASF subversion and git services commented on SOLR-16921:


Commit 9fcc61ce31315254d62c838f55c776c8abd34546 in solr's branch 
refs/heads/branch_9x from Eric Pugh
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=9fcc61ce313 ]

SOLR-16921: use -solrUrl to derive the zk host connection for bin/solr zk 
subcommands (#2370)


> bin/solr upconfig and downconfig reference solrUrl but don't list it as 
> option!
> ---
>
> Key: SOLR-16921
> URL: https://issues.apache.org/jira/browse/SOLR-16921
> Project: Solr
>  Issue Type: Sub-task
>  Components: cli
>Affects Versions: main (10.0), 9.3
>Reporter: Eric Pugh
>Assignee: Eric Pugh
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We have a message like:
>  if (zkHost == null) {
>   throw new IllegalStateException(
>   "Solr at "
>   + cli.getOptionValue("solrUrl")
>   + " is running in standalone server mode, upconfig can only be 
> used when running in SolrCloud mode.\n");
> }
> but we don't declare the option value of solrUrl..  
> Although, why not???



--
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-16921) bin/solr upconfig and downconfig reference solrUrl but don't list it as option!

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-16921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841945#comment-17841945
 ] 

ASF subversion and git services commented on SOLR-16921:


Commit f9f9905aebbc4179e76fd22f182aeee75f7273a3 in solr's branch 
refs/heads/main from Eric Pugh
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=f9f9905aebb ]

SOLR-16921: use -solrUrl to derive the zk host connection for bin/solr zk 
subcommands (#2370)



> bin/solr upconfig and downconfig reference solrUrl but don't list it as 
> option!
> ---
>
> Key: SOLR-16921
> URL: https://issues.apache.org/jira/browse/SOLR-16921
> Project: Solr
>  Issue Type: Sub-task
>  Components: cli
>Affects Versions: main (10.0), 9.3
>Reporter: Eric Pugh
>Assignee: Eric Pugh
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We have a message like:
>  if (zkHost == null) {
>   throw new IllegalStateException(
>   "Solr at "
>   + cli.getOptionValue("solrUrl")
>   + " is running in standalone server mode, upconfig can only be 
> used when running in SolrCloud mode.\n");
> }
> but we don't declare the option value of solrUrl..  
> Although, why not???



--
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-16921: use -solrUrl to derive the zk host connection for bin/solr zk subcommands [solr]

[via GitHub]

epugh merged PR #2370:
URL: https://github.com/apache/solr/pull/2370


-- 
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]

[via GitHub]

epugh commented on PR #2417:
URL: https://github.com/apache/solr/pull/2417#issuecomment-2082391283

   Gentle ping @dsmiley @laminelam did we get to a decision?  Rename the ticket 
and move forward? 


-- 
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-12813: subqueries should respect basic auth [solr]

[via GitHub]

epugh commented on PR #2404:
URL: https://github.com/apache/solr/pull/2404#issuecomment-2082388354

   Thanks @rseitz  for the contribution.   Tag me on the `security.json` 
refactor please!


-- 
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-17237) JSON Writer appears to return invalid JSON when binary fields are used

[Mikhail Khludnev (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-17237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev resolved SOLR-17237.
-
Fix Version/s: 9.6.0
   Resolution: Fixed

> 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.0
>
> 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

[Karl Stoney (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-17237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Stoney updated SOLR-17237:
---
Attachment: Screenshot 2024-04-29 at 08.54.30.png

> 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
> 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] [Commented] (SOLR-17237) JSON Writer appears to return invalid JSON when binary fields are used

[Karl Stoney (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-17237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841887#comment-17841887
 ] 

Karl Stoney commented on SOLR-17237:


Hello!
Sorry for the delay in getting back to you, I was away last week.

Whilst I was off - someone at work debugged it:

Problem's here in 9.5.0 release
https://github.com/apache/solr/blob/cdd27dd15c3a6574032e9b1b92b148ab4e383599/solr/core/src/java/org/apache/solr/schema/BinaryField.java#L61

BinaryField tells the response writer the field doesn't need escaping, then the 
Jackson writer it's picked uses that to write the raw value
https://github.com/apache/solr/blob/cdd27dd15c3a6574032e9b1b92b148ab4e383599/solr/core/src/java/org/apache/solr/response/JacksonJsonWriter.java#L131

I was going to submit a PR as it's just a case of ignoring the fields hint, 
then realised someone already fixed it last month for their UUID type problem, 
which also fixes binary
https://issues.apache.org/jira/browse/SOLR-17110
https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/response/JacksonJsonWriter.java#L131

I bumped our cluster to 9.6.0 this morning and can confirm the binary field is 
now quoted:

 !Screenshot 2024-04-29 at 08.54.30.png! 


> 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
> 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