Re: [PR] SOLR-14115: Allow bin/solr zk commands to have parity with zkcli.sh commands. [solr]
epugh commented on PR #2298: URL: https://github.com/apache/solr/pull/2298#issuecomment-1975205848 @gus-asf would love your review of commit 2efdcdbc4174c4517cfc59e8fd8f42cf0bb0ec95 specifically! -- 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-7233) rename zkcli.sh script it clashes with zkCli.sh from ZooKeeper on Mac when both are in $PATH
[ https://issues.apache.org/jira/browse/SOLR-7233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17822957#comment-17822957 ] Eric Pugh commented on SOLR-7233: - I noticed in [https://solr.apache.org/guide/solr/latest/deployment-guide/taking-solr-to-production.html#zookeeper-chroot] a reference to the "bootstrap" capablity. I feel like that is an older artifact that isn't used, and we never listed it as something to port to bin/solr zk subcommands. I'm not going to preserve it unless someone speaks up that it's actually a "good thing". It feels very opaque to use... and I suspect isn't actually used! > rename zkcli.sh script it clashes with zkCli.sh from ZooKeeper on Mac when > both are in $PATH > > > Key: SOLR-7233 > URL: https://issues.apache.org/jira/browse/SOLR-7233 > Project: Solr > Issue Type: Task > Components: scripts and tools >Affects Versions: 4.10 >Reporter: Hari Sekhon >Priority: Trivial > > Mac is case insensitive on CLI search so zkcli.sh clashes with zkCli.sh from > ZooKeeper when both are in the $PATH, ruining commands for one or the other > unless the script path is qualified. -- 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] (SOLR-7233) rename zkcli.sh script it clashes with zkCli.sh from ZooKeeper on Mac when both are in $PATH
[ https://issues.apache.org/jira/browse/SOLR-7233 ] Eric Pugh deleted comment on SOLR-7233: - was (Author: epugh): I noticed in [https://solr.apache.org/guide/solr/latest/deployment-guide/taking-solr-to-production.html#zookeeper-chroot] a reference to the "bootstrap" capablity. I feel like that is an older artifact that isn't used, and we never listed it as something to port to bin/solr zk subcommands. I'm not going to preserve it unless someone speaks up that it's actually a "good thing". It feels very opaque to use... and I suspect isn't actually used! > rename zkcli.sh script it clashes with zkCli.sh from ZooKeeper on Mac when > both are in $PATH > > > Key: SOLR-7233 > URL: https://issues.apache.org/jira/browse/SOLR-7233 > Project: Solr > Issue Type: Task > Components: scripts and tools >Affects Versions: 4.10 >Reporter: Hari Sekhon >Priority: Trivial > > Mac is case insensitive on CLI search so zkcli.sh clashes with zkCli.sh from > ZooKeeper when both are in the $PATH, ruining commands for one or the other > unless the script path is qualified. -- 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
[ https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17822964#comment-17822964 ] Eric Pugh commented on SOLR-14115: -- I noticed in [https://solr.apache.org/guide/solr/latest/deployment-guide/taking-solr-to-production.html#zookeeper-chroot] a reference to the "bootstrap" capablity. I feel like that is an older artifact that isn't used, and we never listed it as something to port to bin/solr zk subcommands. I'm not going to preserve it unless someone speaks up that it's actually a "good thing". It feels very opaque to use... and I suspect isn't actually used! > 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: 40m > 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-7074) Simple script to start external Zookeeper
[ https://issues.apache.org/jira/browse/SOLR-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17822966#comment-17822966 ] Eric Pugh commented on SOLR-7074: - Need to start up zookeeper? do this. docker run --name my-zookeeper -p 2181:2181 -d zookeeper Going to close this as won't do. > Simple script to start external Zookeeper > - > > Key: SOLR-7074 > URL: https://issues.apache.org/jira/browse/SOLR-7074 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Upayavira >Priority: Major > > When starting Zookeeper for SolrCloud, we have two choices, bin/solr -c > (without -z) and run Zookeeper embedded. Whilst this works, it is suggestive > of bad practice, something you will have to unlearn later. > The second option is to download Zookeeper, and install it manually. This > isn't hugely hard, but it is quite manual. However, try it on Windows, and > you'll find the Windows start script for Zookeeper is extremely thin (no > start/stop options, etc). > Solr contains everything needed to start Zookeeper. Why not have a bin/zk > script that can start it for us. Thus, first time user instructions for > ZolrCloud could be: > bin/zk start > bin/zk uploadconf examples/techproducts/conf > bin/solr start -c -Z > -Z here hypothetically says "look in the standard place, localhost:2181, for > Zookeeper". > or even: > bin/zk start -config=examples/techproducts/conf > bin/ssolr start -Z > This should support both Windows and Unix. > bin/zk would support all the functionality of the current zkCli scripts as > well as being able to start/stop zookeeper. > This would make initial experience of using Solr a lot simpler, in my view, > which would be a good thing. > Not only that, deploying Zookeeper in production, for Solr, need only be push > a Solr app dir to the server, then run bin/zk start, reducing the complexity > of installation. > Thoughts? If this seems like a good idea, and don't share valid objections, > I'm prepared to make it happen. -- 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-7074) Simple script to start external Zookeeper
[ https://issues.apache.org/jira/browse/SOLR-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-7074. - Resolution: Workaround > Simple script to start external Zookeeper > - > > Key: SOLR-7074 > URL: https://issues.apache.org/jira/browse/SOLR-7074 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Upayavira >Priority: Major > > When starting Zookeeper for SolrCloud, we have two choices, bin/solr -c > (without -z) and run Zookeeper embedded. Whilst this works, it is suggestive > of bad practice, something you will have to unlearn later. > The second option is to download Zookeeper, and install it manually. This > isn't hugely hard, but it is quite manual. However, try it on Windows, and > you'll find the Windows start script for Zookeeper is extremely thin (no > start/stop options, etc). > Solr contains everything needed to start Zookeeper. Why not have a bin/zk > script that can start it for us. Thus, first time user instructions for > ZolrCloud could be: > bin/zk start > bin/zk uploadconf examples/techproducts/conf > bin/solr start -c -Z > -Z here hypothetically says "look in the standard place, localhost:2181, for > Zookeeper". > or even: > bin/zk start -config=examples/techproducts/conf > bin/ssolr start -Z > This should support both Windows and Unix. > bin/zk would support all the functionality of the current zkCli scripts as > well as being able to start/stop zookeeper. > This would make initial experience of using Solr a lot simpler, in my view, > which would be a good thing. > Not only that, deploying Zookeeper in production, for Solr, need only be push > a Solr app dir to the server, then run bin/zk start, reducing the complexity > of installation. > Thoughts? If this seems like a good idea, and don't share valid objections, > I'm prepared to make it happen. -- 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-16505: Switch UpdateShardHandler.getRecoveryOnlyHttpClient to Jetty HTTP2 [solr]
iamsanjay commented on PR #2276: URL: https://github.com/apache/solr/pull/2276#issuecomment-1975233648 @dsmiley I was working on IndexFetcher to change their client to Http2SolrClient. Suddenly all the request started failing due to authentication issue. Further inspection revealed that the listener required for Auth is not registered for recoveryOnlyClient. Interestingly, no calls in RecoveryStrategy requires Auth, and therefore no request failed there. Below is the code, that called on updateOnlyClient to register the Auth listener. https://github.com/apache/solr/blob/1c6798b0a012f47ab88ed091b9015462016dc8e8/solr/core/src/java/org/apache/solr/update/UpdateShardHandler.java#L317-L319 However, only calling this method for recoveryOnlyClient won't work. As recreating Http2SolrClient using withHttpClient won't pass on listeners. Basically same issue that we have faced with Executors. -- 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-11535: Fix race condition in singleton-per-collection StateWatcher creation [solr]
noblepaul commented on code in PR #1964:
URL: https://github.com/apache/solr/pull/1964#discussion_r1510478108
##
solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java:
##
@@ -1679,19 +1698,21 @@ public static String getCollectionPath(String coll) {
* @see ZkStateReader#unregisterCore(String)
*/
public void registerCore(String collection) {
-AtomicBoolean reconstructState = new AtomicBoolean(false);
+AtomicReference newWatcherRef = new AtomicReference<>();
collectionWatches.compute(
collection,
(k, v) -> {
if (v == null) {
-reconstructState.set(true);
-v = new StatefulCollectionWatch();
+StateWatcher stateWatcher = new StateWatcher(collection);
Review Comment:
Can we replace this with
can we replace this with
```
v = new StatefulCollectionWatch(new StateWatcher(collection));
newWatcherRef.set(v.associatedWatcher);
```
--
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-11535: Fix race condition in singleton-per-collection StateWatcher creation [solr]
noblepaul commented on code in PR #1964:
URL: https://github.com/apache/solr/pull/1964#discussion_r1510478108
##
solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java:
##
@@ -1679,19 +1698,21 @@ public static String getCollectionPath(String coll) {
* @see ZkStateReader#unregisterCore(String)
*/
public void registerCore(String collection) {
-AtomicBoolean reconstructState = new AtomicBoolean(false);
+AtomicReference newWatcherRef = new AtomicReference<>();
collectionWatches.compute(
collection,
(k, v) -> {
if (v == null) {
-reconstructState.set(true);
-v = new StatefulCollectionWatch();
+StateWatcher stateWatcher = new StateWatcher(collection);
Review Comment:
can we replace this with
```
v = new StatefulCollectionWatch(new StateWatcher(collection));
newWatcherRef.set(v.associatedWatcher);
```
--
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-11535: Fix race condition in singleton-per-collection StateWatcher creation [solr]
noblepaul commented on code in PR #1964:
URL: https://github.com/apache/solr/pull/1964#discussion_r1510479018
##
solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java:
##
@@ -1763,26 +1784,29 @@ public void registerCollectionStateWatcher(
* The Watcher will automatically be removed when it's
onStateChanged returns
* true
*/
- public void registerDocCollectionWatcher(String collection,
DocCollectionWatcher stateWatcher) {
-AtomicBoolean watchSet = new AtomicBoolean(false);
+ public void registerDocCollectionWatcher(
+ String collection, DocCollectionWatcher docCollectionWatcher) {
+AtomicReference newWatcherRef = new AtomicReference<>();
collectionWatches.compute(
collection,
(k, v) -> {
if (v == null) {
-v = new StatefulCollectionWatch();
-watchSet.set(true);
+StateWatcher stateWatcher = new StateWatcher(collection);
Review Comment:
same here too
```
v = new StatefulCollectionWatch(new StateWatcher(collection));
newWatcherRef.set(v.associatedWatcher);
```
--
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
