[GitHub] [solr] psalagnac commented on pull request #1465: SOLR-16705: Remove useless Zookeeper checks
psalagnac commented on PR #1465: URL: https://github.com/apache/solr/pull/1465#issuecomment-1486416452 Hi @markrmiller, Thanks for looking into this. Is this change good to be merged? Is something else required? Thanks -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16465) Start the migration of the Admin UI to React
[ https://issues.apache.org/jira/browse/SOLR-16465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17705878#comment-17705878 ] Jan Høydahl commented on SOLR-16465: FYI: https://lists.apache.org/thread/nfm6jj41bop7773wvomk01oltdtny6gx > Start the migration of the Admin UI to React > > > Key: SOLR-16465 > URL: https://issues.apache.org/jira/browse/SOLR-16465 > Project: Solr > Issue Type: Wish > Components: Admin UI >Reporter: Jeb Nix >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > I suggest using > [ngUpgrade|https://angular.io/guide/upgrade#upgrading-with-ngupgrade] to > start a linear migration process to Angular from Angular JS. ngUpgrade will > reach the end of life at the end of 2023, so we will only get a year of using > it seamlessly, but this seems to me like the last resort regarding a linear > migration of the Admin UI codebase. The need for this is of course to migrate > the current Admin UI project to newer technology, instead of writing it all > from the start (or implementing the same stuff once more in YASA). -- 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-16601) Remove Deprecated Methods from Solr Clients
[ https://issues.apache.org/jira/browse/SOLR-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17705935#comment-17705935 ] Eric Pugh commented on SOLR-16601: -- This is ready for review! Can removing the deprecated methods be applied to branch_9x for release in 9.3? Or can it only go on main for Solr 10? > Remove Deprecated Methods from Solr Clients > --- > > Key: SOLR-16601 > URL: https://issues.apache.org/jira/browse/SOLR-16601 > Project: Solr > Issue Type: Sub-task > Components: clients - java >Affects Versions: main (10.0), 9.2 >Reporter: Eric Pugh >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > Let's simplify our code base by removing the deprecated methods from the > various client builders. > I am hoping that there is a point in time that we can remove ALL the > deprecated methods at once, so that users of SolrClients can move to the > Builder pattern just once, and we can call it out big time in the release > notes. > What are the specifics of removing deprecated methods? Where do we docuemnt > that? -- 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-16601) Remove Deprecated Methods from Solr Clients
[ https://issues.apache.org/jira/browse/SOLR-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-16601: Assignee: Eric Pugh > Remove Deprecated Methods from Solr Clients > --- > > Key: SOLR-16601 > URL: https://issues.apache.org/jira/browse/SOLR-16601 > Project: Solr > Issue Type: Sub-task > Components: clients - java >Affects Versions: main (10.0), 9.2 >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > Let's simplify our code base by removing the deprecated methods from the > various client builders. > I am hoping that there is a point in time that we can remove ALL the > deprecated methods at once, so that users of SolrClients can move to the > Builder pattern just once, and we can call it out big time in the release > notes. > What are the specifics of removing deprecated methods? Where do we docuemnt > that? -- 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
[GitHub] [solr] risdenk opened a new pull request, #1498: Cleanup commons lang3
risdenk opened a new pull request, #1498: URL: https://github.com/apache/solr/pull/1498 https://issues.apache.org/jira/browse/SOLR-X This is NOT ready for review yet. This just works down the list of commons lang3 usages and tries to replace them with JDK methods where possible. -- 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
[GitHub] [solr] epugh opened a new pull request, #1499: SOLR-16604: Use the Builders directly in unit tests
epugh opened a new pull request, #1499: URL: https://github.com/apache/solr/pull/1499 https://issues.apache.org/jira/browse/SOLR-16604 # Description Swap to using Builder directly. # Solution Using the non deprecated version of the Builders where possible, so as not to just add more use of the deprecate SolrClients. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] 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
[GitHub] [solr] epugh commented on pull request #1499: SOLR-16604: Use the Builders directly in unit tests
epugh commented on PR #1499: URL: https://github.com/apache/solr/pull/1499#issuecomment-1486887898 @dsmiley starting the migration ;-) -- 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
[GitHub] [solr-operator] HoustonPutman commented on pull request #343: Use global.imagePullSecrets at solr-operator helm chart #338
HoustonPutman commented on PR #343: URL: https://github.com/apache/solr-operator/pull/343#issuecomment-1487014768 @piotrrybicki Please open your own PR. We'd love to support as many globals as possible, to make setup easy for everyone! As for my comment above it would be great if the helm code could detect a list of strings and convert it to a list of objects where necessary. -- 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
[GitHub] [solr-operator] HoustonPutman commented on issue #534: zk provided pvc
HoustonPutman commented on issue #534: URL: https://github.com/apache/solr-operator/issues/534#issuecomment-1487027991 Ahh so it looks like the zookeeper operator does support additional volumes, but the solr operator doesn't allow that functionality. We should make a PR to add the additional functionality not supported by the Solr Operator. -- 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
[GitHub] [solr-operator] HoustonPutman commented on issue #533: Default liveliness and readiness probes return 401
HoustonPutman commented on issue #533: URL: https://github.com/apache/solr-operator/issues/533#issuecomment-1487041283 Under `authentication` I think you need to add `"blockUnknown": false`. You are authorized for those endpoints, but since you are not providing the basic auth header, you are getting rejected because you are not authenticated. In the docs you can find the following snippet: > A few aspects of the default security.json configuration warrant a closer look. First, the probesRequireAuth setting (defaults to false) governs the value for blockUnknown (under authentication) and whether the probe endpoint(s) require authentication: -- 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
[GitHub] [solr-operator] HoustonPutman opened a new issue, #535: Allow sessionAffinity for the SolrCloud CommonService
HoustonPutman opened a new issue, #535: URL: https://github.com/apache/solr-operator/issues/535 Kubernetes ClusterIP Services allow for sessionAffinity, and customization of the max session stickiness timeout. More information can be found here: https://kubernetes.io/docs/reference/networking/virtual-ips/#session-affinity All we would need is these options to be given under `SolrCloud.Spec.customSolrKubeOptions.commonServiceOptions`, and then passed to the service. This doesn't make sense for the headless service or node services. -- 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.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
[GitHub] [solr-operator] GiuseppeCSI commented on issue #533: Default liveliness and readiness probes return 401
GiuseppeCSI commented on issue #533: URL: https://github.com/apache/solr-operator/issues/533#issuecomment-1487088565 I think i misinterpreted this part > First, the probesRequireAuth setting (defaults to false) governs the value for blockUnknown (under authentication) and whether the probe endpoint(s) require authentication I thought it meant that it would pilot the value for blockUnknown in general and not only for the auto bootstrapped security json. Anyways, i tried to add `"blockUnknown": false` to my security.json authentication part, but no luck. The pod dies as usual and if i describe it, it says ``` Warning Unhealthy 104s (x7 over 2m14s) kubelet Readiness probe failed: HTTP probe failed with statuscode: 401 Warning Unhealthy 104s (x3 over 2m4s) kubelet Liveness probe failed: HTTP probe failed with statuscode: 401 ``` -- 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
[GitHub] [solr] solrbot closed pull request #1492: Update dependency io.swagger.core.v3:swagger-annotations to v2.2.9 - autoclosed
solrbot closed pull request #1492: Update dependency io.swagger.core.v3:swagger-annotations to v2.2.9 - autoclosed URL: https://github.com/apache/solr/pull/1492 -- 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-16601) Remove Deprecated Methods from Solr Clients
[ https://issues.apache.org/jira/browse/SOLR-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706061#comment-17706061 ] Jan Høydahl commented on SOLR-16601: All public facing SolrJ code deprecated after 9.0 must remain in 9.x, so remove in main. > Remove Deprecated Methods from Solr Clients > --- > > Key: SOLR-16601 > URL: https://issues.apache.org/jira/browse/SOLR-16601 > Project: Solr > Issue Type: Sub-task > Components: clients - java >Affects Versions: main (10.0), 9.2 >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > Let's simplify our code base by removing the deprecated methods from the > various client builders. > I am hoping that there is a point in time that we can remove ALL the > deprecated methods at once, so that users of SolrClients can move to the > Builder pattern just once, and we can call it out big time in the release > notes. > What are the specifics of removing deprecated methods? Where do we docuemnt > that? -- 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
[GitHub] [solr] sonatype-lift[bot] commented on a diff in pull request #1498: Cleanup commons lang3
sonatype-lift[bot] commented on code in PR #1498:
URL: https://github.com/apache/solr/pull/1498#discussion_r1150808170
##
solr/core/src/java/org/apache/solr/cloud/ExclusiveSliceProperty.java:
##
@@ -76,13 +77,13 @@ class ExclusiveSliceProperty {
ExclusiveSliceProperty(ClusterState clusterState, ZkNodeProps message) {
this.clusterState = clusterState;
String tmp = message.getStr(ZkStateReader.PROPERTY_PROP);
-if (!StringUtils.startsWith(tmp, CollectionAdminParams.PROPERTY_PREFIX)) {
+if (!tmp.startsWith(CollectionAdminParams.PROPERTY_PREFIX)) {
Review Comment:
https://lift.sonatype.com/api/commentimage/fixrate/5/display.svg";>
*NULLPTR_DEREFERENCE:* `tmp` could be null (last assigned on line
69) and is dereferenced.
---
ℹ️ Expand to see all @sonatype-lift
commands
You can reply with the following commands. For example, reply with
***@sonatype-lift ignoreall*** to leave out all findings.
| **Command** | **Usage** |
| - | - |
| `@sonatype-lift ignore` | Leave out the above finding from this PR |
| `@sonatype-lift ignoreall` | Leave out all the existing findings from this
PR |
| `@sonatype-lift exclude ` | Exclude specified
`file\|issue\|path\|tool` from Lift findings by updating your config.toml file |
**Note:** When talking to LiftBot, you need to **refresh** the page to see
its response.
[Click here](https://github.com/apps/sonatype-lift/installations/new)
to add LiftBot to another repo.
---
Help us improve LIFT! (Sonatype LiftBot external survey)
Was this a good recommendation for you? Answering this survey
will not impact your Lift settings.
[ [🙁 Not
relevant](https://www.sonatype.com/lift-comment-rating?comment=462143147&lift_comment_rating=1)
] - [ [😕 Won't
fix](https://www.sonatype.com/lift-comment-rating?comment=462143147&lift_comment_rating=2)
] - [ [😑 Not critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=462143147&lift_comment_rating=3)
] - [ [🙂 Critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=462143147&lift_comment_rating=4)
] - [ [😊 Critical, fixing
now](https://www.sonatype.com/lift-comment-rating?comment=462143147&lift_comment_rating=5)
]
##
solr/core/src/java/org/apache/solr/cloud/ExclusiveSliceProperty.java:
##
@@ -76,13 +77,13 @@ class ExclusiveSliceProperty {
ExclusiveSliceProperty(ClusterState clusterState, ZkNodeProps message) {
this.clusterState = clusterState;
String tmp = message.getStr(ZkStateReader.PROPERTY_PROP);
-if (!StringUtils.startsWith(tmp, CollectionAdminParams.PROPERTY_PREFIX)) {
+if (!tmp.startsWith(CollectionAdminParams.PROPERTY_PREFIX)) {
Review Comment:
https://lift.sonatype.com/api/commentimage/fixrate/15/display.svg";>
*NULL_DEREFERENCE:* object `tmp` last assigned on line 79 could be
null and is dereferenced at line 80.
---
ℹ️ Expand to see all @sonatype-lift
commands
You can reply with the following commands. For example, reply with
***@sonatype-lift ignoreall*** to leave out all findings.
| **Command** | **Usage** |
| - | - |
| `@sonatype-lift ignore` | Leave out the above finding from this PR |
| `@sonatype-lift ignoreall` | Leave out all the existing findings from this
PR |
| `@sonatype-lift exclude ` | Exclude specified
`file\|issue\|path\|tool` from Lift findings by updating your config.toml file |
**Note:** When talking to LiftBot, you need to **refresh** the page to see
its response.
[Click here](https://github.com/apps/sonatype-lift/installations/new)
to add LiftBot to another repo.
---
Help us improve LIFT! (Sonatype LiftBot external survey)
Was this a good recommendation for you? Answering this survey
will not impact your Lift settings.
[ [🙁 Not
relevant](https://www.sonatype.com/lift-comment-rating?comment=462146435&lift_comment_rating=1)
] - [ [😕 Won't
fix](https://www.sonatype.com/lift-comment-rating?comment=462146435&lift_comment_rating=2)
] - [ [😑 Not critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=462146435&lift_comment_rating=3)
] - [ [🙂 Critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=462146435&lift_comment_rating=4)
] - [ [😊 Critical, fixing
now](https://www.sonatype.com/lift-comment-rating?comment=462146435&lift_comment_rating=5)
]
--
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: is
[GitHub] [solr-operator] HoustonPutman commented on issue #529: Support disruption free rolling restart
HoustonPutman commented on issue #529: URL: https://github.com/apache/solr-operator/issues/529#issuecomment-1487136250 @janhoy we should also create a Solr JIRA issue for this, to fix Cloud-aware clients and internal shard requests. More info: We can fix this for simple use cases where users have clouds that all collections are single-sharded and each collection has a replica on all nodes. That way, Solr has no need to send the request to another node internally. If a collection is multi-sharded, or a replica of the collection does not exist on all nodes, then Solr might have to forward requests throughout the cluster. Solr is not aware of the podConditions we are using to solve this in Kubernetes, so we need to think of another solution to fix this inside of Solr. In the meantime #530 is a great start. -- 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
[GitHub] [solr] janhoy commented on a diff in pull request #1496: SOLR-16601: Remove Deprecated Methods from SolrClients
janhoy commented on code in PR #1496:
URL: https://github.com/apache/solr/pull/1496#discussion_r1150844208
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/ConcurrentUpdateSolrClient.java:
##
@@ -116,12 +114,23 @@ protected ConcurrentUpdateSolrClient(Builder builder) {
this.streamDeletes = builder.streamDeletes;
this.connectionTimeout = Math.toIntExact(builder.connectionTimeoutMillis);
this.soTimeout = Math.toIntExact(builder.socketTimeoutMillis);
-this.stallTime = Integer.getInteger("solr.cloud.client.stallTime", 15000);
-if (stallTime < pollQueueTime * 2) {
+this.pollQueueTimeMillis = builder.pollQueueTime;
+this.stallTimeMillis = Integer.getInteger("solr.cloud.client.stallTime",
15000);
+
+// make sure the stall time is larger than the polling time
+// to give a chance for the queue to change
+int minimalStallTime = pollQueueTimeMillis * 2;
+if (minimalStallTime > this.stallTimeMillis) {
+ this.stallTimeMillis = minimalStallTime;
+}
Review Comment:
Should these changes, and the one below, be in a separate 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
[GitHub] [solr-operator] HoustonPutman closed issue #532: Updating Solr Document Results Duplicate Versions
HoustonPutman closed issue #532: Updating Solr Document Results Duplicate Versions URL: https://github.com/apache/solr-operator/issues/532 -- 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
[GitHub] [solr-operator] HoustonPutman commented on issue #532: Updating Solr Document Results Duplicate Versions
HoustonPutman commented on issue #532: URL: https://github.com/apache/solr-operator/issues/532#issuecomment-1487210778 I'd post this question to the [solr users list](https://solr.apache.org/community.html#mailing-lists-chat), since this question is purely about Solr and not about interactions with Kubernetes. -- 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
[GitHub] [solr-operator] HoustonPutman commented on issue #533: Default liveliness and readiness probes return 401
HoustonPutman commented on issue #533: URL: https://github.com/apache/solr-operator/issues/533#issuecomment-1487217238 Did you try to update an existing cluster or create a new one? Also even if you deleted and recreated, you need to make sure that Zookeeper didn't use the same persistent volumes as before. Because if the security.json already exists in Solr it won't update it. If the documentation was confusing, we always appreciate contributions (especially for docs)! -- 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
[GitHub] [solr-operator] janhoy commented on a diff in pull request #530: Add readinessCondition to stop traffic to pods that will be stopped
janhoy commented on code in PR #530:
URL: https://github.com/apache/solr-operator/pull/530#discussion_r1150958026
##
controllers/util/solr_update_util_test.go:
##
@@ -180,6 +205,26 @@ func TestPickPodsToUpgrade(t *testing.T) {
solrCloud.Spec.Replicas = Replicas(4)
podsToUpgrade = getPodNames(pickPodsToUpdate(solrCloud, lastPod,
testHealthyClusterStatus, overseerLeader, 6, log))
assert.ElementsMatch(t, []string{"foo-solrcloud-0"}, podsToUpgrade,
"Incorrect set of next pods to upgrade. The overseer should be upgraded when
everything is healthy and it is the last node, even though this SolrCloud
resource doesn't manage all Nodes")
+
+ /*
+ Test when some pods have already been selected for deletion
+ */
+
+ // Normal inputs
+ maxshardReplicasUnavailable = intstr.FromInt(1)
+ podsToUpgrade = getPodNames(pickPodsToUpdate(solrCloud,
someScheduledForDeletionPods, testHealthyClusterStatus, overseerLeader, 6, log))
+ assert.ElementsMatch(t, []string{}, podsToUpgrade, "Incorrect set of
next pods to upgrade. Do to replica placement, only the node with the least
leaders can be upgraded and replicas.")
Review Comment:
*Due* to?
##
docs/solr-cloud/managed-updates.md:
##
@@ -89,3 +89,25 @@ spec:
annotations:
manualrestart: "2021-10-20T08:37:00Z"
```
+
+## Pod Readiness during updates
+
+The Solr Operator sets up at least two Services for every SolrCloud.
+- Always
+ - A clusterIP service for all solr nodes (What we call the "common service")
+- Either
+ - A [Headless
Service](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services)
for individual Solr Node endpoints that are not exposed via an Ingress.
+ - Individual clusterIP services for Solr Nodes that are exposed via an
Ingress
+
+Only the common service uses the `publishNotReadyAddresses: false` option,
since the common service should load balance between all available nodes.
+The second two services have individual endpoints for each node, so there is
no reason to de-list pods that are not available.
Review Comment:
```suggestion
The other services have individual endpoints for each node, so there is no
reason to de-list pods that are not available.
```
##
docs/upgrade-notes.md:
##
@@ -120,6 +120,12 @@ _Note that the Helm chart version does not contain a `v`
prefix, which the downl
- Provided Zookeeper pods use the `IfNotPresent` pullPolicy by default. Users
that specify this field manually will not see a change.
+- The Solr Operator now tries to limit connectivity to pods before they are
deleted, for rolling updates or other reasons.
+ Before the pod is killed, and evicted of replicas if ephemeral storage is
used, a readinessCondition will be set to `false`.
+ The Headless Service does not use readiness, so internode traffic will not
be affected, however the ClusterIP service will no longer include these nodes
until they have been restarted.
Review Comment:
```suggestion
The Headless Service does not use readiness, so internode traffic will not
be affected, however the ClusterIP (common) service will no longer include
these nodes until they have been restarted.
```
--
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
[GitHub] [solr-operator] janhoy commented on issue #529: Support disruption free rolling restart
janhoy commented on issue #529: URL: https://github.com/apache/solr-operator/issues/529#issuecomment-1487367447 > @janhoy we should also create a Solr JIRA issue for this, to fix Cloud-aware clients and internal shard requests. Sure, I can create one. Do you have a clear idea of how it would work? Now, SolrJ considers collection-state combined with `live_nodes` to decide what replicas to query. Would we need some new per-node-state znode in Zookeeper to flag a node as "draining", and then let SolrJ act on that? -- 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
[GitHub] [solr] risdenk opened a new pull request, #1500: remove-collections4
risdenk opened a new pull request, #1500: URL: https://github.com/apache/solr/pull/1500 https://issues.apache.org/jira/browse/SOLR-X -- 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
[GitHub] [solr] janhoy commented on a diff in pull request #1500: remove-collections4
janhoy commented on code in PR #1500:
URL: https://github.com/apache/solr/pull/1500#discussion_r115011
##
solr/core/src/java/org/apache/solr/search/SolrDocumentFetcher.java:
##
@@ -762,7 +761,7 @@ private boolean returnStoredFields() {
}
private boolean returnDVFields() {
- return CollectionUtils.isNotEmpty(dvFields);
+ return !(dvFields != null && dvFields.isEmpty());
Review Comment:
A comment in line 738 says `dvFields` is always not null, not can simplify
```suggestion
return !dvFields.isEmpty();
```
--
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
[GitHub] [solr] janhoy merged pull request #1489: Remove duplicate code fragments in StreamingTest
janhoy merged PR #1489: URL: https://github.com/apache/solr/pull/1489 -- 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
[GitHub] [solr] sonatype-lift[bot] commented on a diff in pull request #1500: remove-collections4
sonatype-lift[bot] commented on code in PR #1500:
URL: https://github.com/apache/solr/pull/1500#discussion_r1151031492
##
solr/core/src/java/org/apache/solr/packagemanager/PackageManager.java:
##
@@ -307,15 +303,14 @@ public Map
getPackagesDeployedAsClusterLevelPlugins
if (pluginMeta.klass.contains(":")) {
String packageName = pluginMeta.klass.substring(0,
pluginMeta.klass.indexOf(':'));
packageVersions.put(packageName, pluginMeta.version);
-packagePlugins.put(packageName, pluginMeta);
+packagePlugins.computeIfAbsent(packageName, k -> new
HashSet<>()).add(pluginMeta);
}
}
Map ret = new HashMap<>();
for (String packageName : packageVersions.keySet()) {
- if (StrUtils.isNullOrEmpty(packageName) == false
- && // There can be an empty key, storing the version here
- packageVersions.get(packageName)
- != null) { // null means the package was undeployed from this
package before
+ // There can be an empty key, storing the version here
+ // null means the package was undeployed from this package before
+ if (!StrUtils.isNullOrEmpty(packageName) &&
packageVersions.get(packageName) != null) {
Review Comment:
https://lift.sonatype.com/api/commentimage/fixrate/10/display.svg";>
*INEFFICIENT_KEYSET_ITERATOR:* Accessing a value using a key that
was retrieved from a `keySet` iterator. It is more efficient to use an iterator
on the `entrySet` of the map, avoiding the extra `HashMap.get(key)` lookup.
---
ℹ️ Expand to see all @sonatype-lift
commands
You can reply with the following commands. For example, reply with
***@sonatype-lift ignoreall*** to leave out all findings.
| **Command** | **Usage** |
| - | - |
| `@sonatype-lift ignore` | Leave out the above finding from this PR |
| `@sonatype-lift ignoreall` | Leave out all the existing findings from this
PR |
| `@sonatype-lift exclude ` | Exclude specified
`file\|issue\|path\|tool` from Lift findings by updating your config.toml file |
**Note:** When talking to LiftBot, you need to **refresh** the page to see
its response.
[Click here](https://github.com/apps/sonatype-lift/installations/new)
to add LiftBot to another repo.
---
Help us improve LIFT! (Sonatype LiftBot external survey)
Was this a good recommendation for you? Answering this survey
will not impact your Lift settings.
[ [🙁 Not
relevant](https://www.sonatype.com/lift-comment-rating?comment=462748469&lift_comment_rating=1)
] - [ [😕 Won't
fix](https://www.sonatype.com/lift-comment-rating?comment=462748469&lift_comment_rating=2)
] - [ [😑 Not critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=462748469&lift_comment_rating=3)
] - [ [🙂 Critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=462748469&lift_comment_rating=4)
] - [ [😊 Critical, fixing
now](https://www.sonatype.com/lift-comment-rating?comment=462748469&lift_comment_rating=5)
]
--
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
[GitHub] [solr-operator] HoustonPutman commented on issue #529: Support disruption free rolling restart
HoustonPutman commented on issue #529: URL: https://github.com/apache/solr-operator/issues/529#issuecomment-1487463171 Not a clear idea yet. > Would we need some new per-node-state znode in Zookeeper to flag a node as "draining", and then let SolrJ act on that? That would work, but I'm not sure we'd want to restrict it to just "draining". We might want to send requests elsewhere for other reasons too. -- 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
[GitHub] [solr] risdenk opened a new pull request, #1501: More guava cleanup
risdenk opened a new pull request, #1501: URL: https://github.com/apache/solr/pull/1501 https://issues.apache.org/jira/browse/SOLR-X -- 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-16668) Use default Java SslContextFactory for HTTP2 when no system properties are given
[
https://issues.apache.org/jira/browse/SOLR-16668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706116#comment-17706116
]
Shawn Heisey commented on SOLR-16668:
-
{quote}Huh, I thought one of our drivers for upgrading was to restore Solr
support in Spring Boot?
{quote}
Maybe in the newest spring boot, I couldn't say. I am using version 2.7.10
because anything newer requires a newer JDK than 11.
The newest spring-data-solr version (4.15.3) is quite far behind – it specifies
SolrJ 8.5.2. That is nearly 3 years old, somebody is not paying attention.
> Use default Java SslContextFactory for HTTP2 when no system properties are
> given
>
>
> Key: SOLR-16668
> URL: https://issues.apache.org/jira/browse/SOLR-16668
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Affects Versions: 9.0
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 9.2
>
> Attachments: image-2023-03-24-23-07-02-247.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Both the Apache and Jetty Http client libraries are capable of defaulting to
> the Java truststores when no system properties are provided. However, when
> cleaning up logging in SOLR-15936 the Http2SolrClient no longer used an
> SSLContextFactory when the system properties were not used. This is a
> regression for users that use the built-in truststore.
>
> Ideally we would be able to use both the default truststore and not give
> extra (useless) logging. If choosing one or the other, I think we should
> choose using the default truststore though.
--
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
[GitHub] [solr-docker] HoustonPutman commented on pull request #14: SOLR-16523 Update the jattach version to 2.1
HoustonPutman commented on PR #14: URL: https://github.com/apache/solr-docker/pull/14#issuecomment-1487473448 Ok so Solr 9.2 officially has jattach 2.0 built in: ``` ❯ docker run -it --rm solr:9.2 jattach --version jattach 2.0 built on Aug 16 2021 ``` So we can put jattach 2.0 in 8.11 now, but not jattach 2.1 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16668) Use default Java SslContextFactory for HTTP2 when no system properties are given
[
https://issues.apache.org/jira/browse/SOLR-16668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706118#comment-17706118
]
Shawn Heisey commented on SOLR-16668:
-
{quote}you might also need to upgrade Spring boot - at least 5.3.26
{quote}
The newest version of Spring Boot that I can find is 3.0.5. I'm using 2.7.10
because I can't use JDK 11 with 3.x. Boot version 2.7.10 uses Spring 5.3.26
components.
> Use default Java SslContextFactory for HTTP2 when no system properties are
> given
>
>
> Key: SOLR-16668
> URL: https://issues.apache.org/jira/browse/SOLR-16668
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Affects Versions: 9.0
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 9.2
>
> Attachments: image-2023-03-24-23-07-02-247.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Both the Apache and Jetty Http client libraries are capable of defaulting to
> the Java truststores when no system properties are provided. However, when
> cleaning up logging in SOLR-15936 the Http2SolrClient no longer used an
> SSLContextFactory when the system properties were not used. This is a
> regression for users that use the built-in truststore.
>
> Ideally we would be able to use both the default truststore and not give
> extra (useless) logging. If choosing one or the other, I think we should
> choose using the default truststore though.
--
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
[GitHub] [solr] janhoy opened a new pull request, #1502: SOLR-16721 Java version detection fails when `_JAVA_OPTIONS` is set
janhoy opened a new pull request, #1502: URL: https://github.com/apache/solr/pull/1502 https://issues.apache.org/jira/browse/SOLR-16721 Simple fix. Removing the `head` filter. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-16721) Java version detection fails when `_JAVA_OPTIONS` is set
[
https://issues.apache.org/jira/browse/SOLR-16721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-16721:
--
Assignee: Jan Høydahl
> Java version detection fails when `_JAVA_OPTIONS` is set
>
>
> Key: SOLR-16721
> URL: https://issues.apache.org/jira/browse/SOLR-16721
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 9.2
> Environment: JDK version:
> {code:java}
> openjdk version "19.0.2" 2023-01-17
> OpenJDK Runtime Environment Homebrew (build 19.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 19.0.2, mixed mode, sharing) {code}
> OS version: macOS 11, 12, 13 (x86_64 and arm64); Ubuntu 22.04 (x86_64)
>Reporter: Ruoyu Zhong
>Assignee: Jan Høydahl
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When the environment variable {{_JAVA_OPTIONS}} is set, {{solr}} fails with
> the following error:
> {code:java}
> $ solr -i
> Your current version of Java is too old to run this version of Solr.
> We found major version , using command
> '/opt/homebrew/opt/openjdk/libexec/openjdk.jdk/Contents/Home/bin/java
> -version', with response:
> Picked up _JAVA_OPTIONS:
> -Duser.home=/Users/brew/Library/Caches/Homebrew/java_cache
> -Djava.io.tmpdir=/private/tmp
> openjdk version "19.0.2" 2023-01-17
> OpenJDK Runtime Environment Homebrew (build 19.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 19.0.2, mixed mode, sharing)
> Please install latest version of Java 11 or set JAVA_HOME properly. {code}
> This is because in the following version check logic (taken from
> [here|https://github.com/apache/solr/blob/a2f6565415663908163f9490856cf0fcfda88b41/solr/bin/solr#L166]),
> only first line of {{java -version}} output is examined:
> {code:java}
> JAVA_VER_NUM=$(echo "$JAVA_VER" | head -1 | awk -F '"' '/version/ {print $2}'
> | sed -e's/^1\.//' | sed -e's/[._-].*$//') {code}
> But as indicated in the output above, {{java}} outputs "{{{}Picked up
> _JAVA_OPTIONS{}}}" on the first line instead, if {{_JAVA_OPTIONS}} is set.
> So, the version on the second line is not picked up.
> I believe that it's [this recent
> change|https://github.com/apache/solr/commit/025c0305fa829baa770f62c81654af8a708753d9]
> (SOLR-9509), which added a pair of quotes around {{{}$JAVA_VER{}}}, that
> introduced this regression. This used to work in an unintended way, because
> Bash treated the unquoted {{$JAVA_VER}} variable as an array of separate
> arguments and output that in a single line. But after introducing the double
> quotes, the newlines in {{$JAVA_VER}} are now preserved.
> {code:java}
> $ JAVA_VER="$(java -version 2>&1)"
> $ echo $JAVA_VER
> Picked up _JAVA_OPTIONS:
> -Duser.home=/Users/ruoyu/Library/Caches/Homebrew/java_cache
> -Djava.io.tmpdir=/private/tmp openjdk version "19.0.2" 2023-01-17 OpenJDK
> Runtime Environment Homebrew (build 19.0.2) OpenJDK 64-Bit Server VM Homebrew
> (build 19.0.2, mixed mode, sharing)
> $ echo "$JAVA_VER"
> Picked up _JAVA_OPTIONS:
> -Duser.home=/Users/ruoyu/Library/Caches/Homebrew/java_cache
> -Djava.io.tmpdir=/private/tmp
> openjdk version "19.0.2" 2023-01-17
> OpenJDK Runtime Environment Homebrew (build 19.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 19.0.2, mixed mode, sharing) {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16721) Java version detection fails when `_JAVA_OPTIONS` is set
[
https://issues.apache.org/jira/browse/SOLR-16721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706133#comment-17706133
]
Jan Høydahl commented on SOLR-16721:
[~zhongruoyu]
I reproduced the issue by setting the _JAVA_OPTIONS var, and just removing the
head pipe fixed it, at least for openjdk temurin. Hopefully other java flavours
will also behave the same. Do you want to test with this patch?
> Java version detection fails when `_JAVA_OPTIONS` is set
>
>
> Key: SOLR-16721
> URL: https://issues.apache.org/jira/browse/SOLR-16721
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 9.2
> Environment: JDK version:
> {code:java}
> openjdk version "19.0.2" 2023-01-17
> OpenJDK Runtime Environment Homebrew (build 19.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 19.0.2, mixed mode, sharing) {code}
> OS version: macOS 11, 12, 13 (x86_64 and arm64); Ubuntu 22.04 (x86_64)
>Reporter: Ruoyu Zhong
>Assignee: Jan Høydahl
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When the environment variable {{_JAVA_OPTIONS}} is set, {{solr}} fails with
> the following error:
> {code:java}
> $ solr -i
> Your current version of Java is too old to run this version of Solr.
> We found major version , using command
> '/opt/homebrew/opt/openjdk/libexec/openjdk.jdk/Contents/Home/bin/java
> -version', with response:
> Picked up _JAVA_OPTIONS:
> -Duser.home=/Users/brew/Library/Caches/Homebrew/java_cache
> -Djava.io.tmpdir=/private/tmp
> openjdk version "19.0.2" 2023-01-17
> OpenJDK Runtime Environment Homebrew (build 19.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 19.0.2, mixed mode, sharing)
> Please install latest version of Java 11 or set JAVA_HOME properly. {code}
> This is because in the following version check logic (taken from
> [here|https://github.com/apache/solr/blob/a2f6565415663908163f9490856cf0fcfda88b41/solr/bin/solr#L166]),
> only first line of {{java -version}} output is examined:
> {code:java}
> JAVA_VER_NUM=$(echo "$JAVA_VER" | head -1 | awk -F '"' '/version/ {print $2}'
> | sed -e's/^1\.//' | sed -e's/[._-].*$//') {code}
> But as indicated in the output above, {{java}} outputs "{{{}Picked up
> _JAVA_OPTIONS{}}}" on the first line instead, if {{_JAVA_OPTIONS}} is set.
> So, the version on the second line is not picked up.
> I believe that it's [this recent
> change|https://github.com/apache/solr/commit/025c0305fa829baa770f62c81654af8a708753d9]
> (SOLR-9509), which added a pair of quotes around {{{}$JAVA_VER{}}}, that
> introduced this regression. This used to work in an unintended way, because
> Bash treated the unquoted {{$JAVA_VER}} variable as an array of separate
> arguments and output that in a single line. But after introducing the double
> quotes, the newlines in {{$JAVA_VER}} are now preserved.
> {code:java}
> $ JAVA_VER="$(java -version 2>&1)"
> $ echo $JAVA_VER
> Picked up _JAVA_OPTIONS:
> -Duser.home=/Users/ruoyu/Library/Caches/Homebrew/java_cache
> -Djava.io.tmpdir=/private/tmp openjdk version "19.0.2" 2023-01-17 OpenJDK
> Runtime Environment Homebrew (build 19.0.2) OpenJDK 64-Bit Server VM Homebrew
> (build 19.0.2, mixed mode, sharing)
> $ echo "$JAVA_VER"
> Picked up _JAVA_OPTIONS:
> -Duser.home=/Users/ruoyu/Library/Caches/Homebrew/java_cache
> -Djava.io.tmpdir=/private/tmp
> openjdk version "19.0.2" 2023-01-17
> OpenJDK Runtime Environment Homebrew (build 19.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 19.0.2, mixed mode, sharing) {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] sonatype-lift[bot] commented on a diff in pull request #1501: More guava cleanup
sonatype-lift[bot] commented on code in PR #1501:
URL: https://github.com/apache/solr/pull/1501#discussion_r1151106048
##
solr/core/src/java/org/apache/solr/logging/jul/JulWatcher.java:
##
@@ -157,7 +158,9 @@ public SolrDocument toSolrDocument(LogRecord event) {
doc.setField("message", event.getMessage().toString());
Throwable t = event.getThrown();
if (t != null) {
- doc.setField("trace", Throwables.getStackTraceAsString(t));
+ StringWriter trace = new StringWriter();
+ t.printStackTrace(new PrintWriter(trace));
Review Comment:
https://lift.sonatype.com/api/commentimage/fixrate/0/display.svg";>
*[INFORMATION_EXPOSURE_THROUGH_AN_ERROR_MESSAGE](https://find-sec-bugs.github.io/bugs.htm#INFORMATION_EXPOSURE_THROUGH_AN_ERROR_MESSAGE):*
Possible information exposure through an error message
---
ℹ️ Expand to see all @sonatype-lift
commands
You can reply with the following commands. For example, reply with
***@sonatype-lift ignoreall*** to leave out all findings.
| **Command** | **Usage** |
| - | - |
| `@sonatype-lift ignore` | Leave out the above finding from this PR |
| `@sonatype-lift ignoreall` | Leave out all the existing findings from this
PR |
| `@sonatype-lift exclude ` | Exclude specified
`file\|issue\|path\|tool` from Lift findings by updating your config.toml file |
**Note:** When talking to LiftBot, you need to **refresh** the page to see
its response.
[Click here](https://github.com/apps/sonatype-lift/installations/new)
to add LiftBot to another repo.
---
Help us improve LIFT! (Sonatype LiftBot external survey)
Was this a good recommendation for you? Answering this survey
will not impact your Lift settings.
[ [🙁 Not
relevant](https://www.sonatype.com/lift-comment-rating?comment=462817520&lift_comment_rating=1)
] - [ [😕 Won't
fix](https://www.sonatype.com/lift-comment-rating?comment=462817520&lift_comment_rating=2)
] - [ [😑 Not critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=462817520&lift_comment_rating=3)
] - [ [🙂 Critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=462817520&lift_comment_rating=4)
] - [ [😊 Critical, fixing
now](https://www.sonatype.com/lift-comment-rating?comment=462817520&lift_comment_rating=5)
]
##
solr/core/src/java/org/apache/solr/logging/log4j2/Log4j2Watcher.java:
##
@@ -272,7 +273,11 @@ public SolrDocument toSolrDocument(LogEvent event) {
Message message = event.getMessage();
doc.setField("message", message.getFormattedMessage());
Throwable t = message.getThrowable();
-if (t != null) doc.setField("trace", Throwables.getStackTraceAsString(t));
+if (t != null) {
+ StringWriter trace = new StringWriter();
+ t.printStackTrace(new PrintWriter(trace));
Review Comment:
https://lift.sonatype.com/api/commentimage/fixrate/0/display.svg";>
*[INFORMATION_EXPOSURE_THROUGH_AN_ERROR_MESSAGE](https://find-sec-bugs.github.io/bugs.htm#INFORMATION_EXPOSURE_THROUGH_AN_ERROR_MESSAGE):*
Possible information exposure through an error message
---
ℹ️ Expand to see all @sonatype-lift
commands
You can reply with the following commands. For example, reply with
***@sonatype-lift ignoreall*** to leave out all findings.
| **Command** | **Usage** |
| - | - |
| `@sonatype-lift ignore` | Leave out the above finding from this PR |
| `@sonatype-lift ignoreall` | Leave out all the existing findings from this
PR |
| `@sonatype-lift exclude ` | Exclude specified
`file\|issue\|path\|tool` from Lift findings by updating your config.toml file |
**Note:** When talking to LiftBot, you need to **refresh** the page to see
its response.
[Click here](https://github.com/apps/sonatype-lift/installations/new)
to add LiftBot to another repo.
---
Help us improve LIFT! (Sonatype LiftBot external survey)
Was this a good recommendation for you? Answering this survey
will not impact your Lift settings.
[ [🙁 Not
relevant](https://www.sonatype.com/lift-comment-rating?comment=462817587&lift_comment_rating=1)
] - [ [😕 Won't
fix](https://www.sonatype.com/lift-comment-rating?comment=462817587&lift_comment_rating=2)
] - [ [😑 Not critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=462817587&lift_comment_rating=3)
] - [ [🙂 Critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=462817587&lift_comment_rating=4)
] - [ [😊 Critical, fixing
now](https://www.sonatype.com/lift-comment-rating?comment=462817587&lift_comment_rating=5)
]
##
solr/core/src/java/org/apache/solr/response/transform/ChildDocTransformer.java:
##
@@ -258,14 +256,14 @@ public void transform(SolrDocument rootDoc, int
rootDocId) {
}
private static void addChildrenToParent(
- SolrDocument parent,
[GitHub] [solr] risdenk commented on a diff in pull request #1496: SOLR-16601: Remove Deprecated Methods from SolrClients
risdenk commented on code in PR #1496:
URL: https://github.com/apache/solr/pull/1496#discussion_r1151109774
##
solr/core/src/test/org/apache/solr/cloud/TestRandomFlRTGCloud.java:
##
@@ -147,6 +148,7 @@ public class TestRandomFlRTGCloud extends SolrCloudTestCase
{
new NotIncludedValidator("score", "score_alias:score"));
@BeforeClass
+ @SuppressWarnings({"rawtypes", "unchecked"})
Review Comment:
why?
##
solr/core/src/test/org/apache/solr/cloud/TestRandomFlRTGCloud.java:
##
@@ -509,13 +523,10 @@ private void assertRTG(final SolrInputDocument[]
knownDocs, final int[] docIds)
}
String wt = params.get(CommonParams.WT, "javabin");
-final ResponseParser restoreResponseParser;
-if (client instanceof HttpSolrClient) {
- restoreResponseParser = modifyParser((HttpSolrClient) client, wt);
-} else {
- // unless HttpSolrClient, `wt` doesn't matter -- it'll always be binary.
+final SolrClient client = getRandomClient(random(), wt);
+// unless HttpSolrClient, `wt` doesn't matter -- it'll always be binary.
+if (client instanceof CloudSolrClient) {
wt = "javabin";
- restoreResponseParser = null;
}
Review Comment:
I don't understand why this is necessary...
##
solr/core/src/test/org/apache/solr/cloud/TestRandomFlRTGCloud.java:
##
@@ -635,12 +644,36 @@ private static SolrDocumentList getDocsFromXmlResponse(
/**
* returns a random SolrClient -- either a CloudSolrClient, or an
HttpSolrClient pointed at a node
- * in our cluster
+ * in our cluster We have different CLIENTS based on their wt setting.
+ */
+ public static SolrClient getRandomClient(Random rand) {
+int numClients = CLIENTS.size();
+int idx = TestUtil.nextInt(rand, 0, numClients);
+if (idx == numClients) {
+ // Return the CloudSolrClient, it only uses javabin writerType.
+ return COLLECTION_CLIENT;
+} else {
+ // Grabbing the first
+ int rnd = random().nextInt(CLIENTS.get(idx).values().toArray().length);
+ return (SolrClient) CLIENTS.get(idx).values().toArray()[rnd];
Review Comment:
Seems very convoluted... no need to create an array twice. Not even sure why
need to create an array?
--
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] [Created] (SOLR-16722) API to flag a solr node NOT READY for requests
Jan Høydahl created SOLR-16722: -- Summary: API to flag a solr node NOT READY for requests Key: SOLR-16722 URL: https://issues.apache.org/jira/browse/SOLR-16722 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Reporter: Jan Høydahl Spinoff from solr operator PR [https://github.com/apache/solr-operator/issues/529] When solr-operator performs a rolling restart or rolling upgrade, it will stop one node at a time, but SolrJ (both external and internal) will continue sending traffic to the node until requests start failing, since at the time SolrJ picks up the "live_nodes" change, it is too late. While the operator PR mentioned above will prevent external requests through the k8s service to the draining node, it will not prevent internal traffic. This issue thus aims to introduce some API or mechanism to flag a Solr node as NOT READY for traffic. -- 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
[GitHub] [solr-operator] janhoy commented on issue #529: Support disruption free rolling restart
janhoy commented on issue #529: URL: https://github.com/apache/solr-operator/issues/529#issuecomment-1487551816 https://issues.apache.org/jira/browse/SOLR-16722 -- 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-16722) API to flag a solr node NOT READY for requests
[
https://issues.apache.org/jira/browse/SOLR-16722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706145#comment-17706145
]
Jan Høydahl commented on SOLR-16722:
One simple option is to create a new top-level znode {{/disabled_nodes}}:
{code:java}
/live_nodes
+-- foo:8983_node
+-- bar:8983_node
/disabled_nodes
+-- bar:8983_node{code}
The znode will normally be empty (or non-existing), but if it exists with >0
children, then those nodes are flagged as disabled for traffic. It could be
because the solr-operator is planning to shut down the node, or it could be a
way to temporarily repel traffic from a node during troubleshooting. SolrJ
would be updated to consider {{disabled_nodes}} in addition to replica-state
and live_nodes. Also CLUSTERSTATUS response should include this information.
The node would still be "live" and will receive traffic, i.e. the znode is only
a signal to SolrJ or other load balancers.
I think disabled_nodes children should be ephemeral so that entries are removed
when a node is shut down, thus it cannot be used to repel traffic from a node
across node restarts.
There could also be a new cluster API to set and clear the znode. We already
have an API (CLUSTERSTATUS) to query it.
> API to flag a solr node NOT READY for requests
> --
>
> Key: SOLR-16722
> URL: https://issues.apache.org/jira/browse/SOLR-16722
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Jan Høydahl
>Priority: Major
>
> Spinoff from solr operator PR
> [https://github.com/apache/solr-operator/issues/529]
> When solr-operator performs a rolling restart or rolling upgrade, it will
> stop one node at a time, but SolrJ (both external and internal) will continue
> sending traffic to the node until requests start failing, since at the time
> SolrJ picks up the "live_nodes" change, it is too late.
> While the operator PR mentioned above will prevent external requests through
> the k8s service to the draining node, it will not prevent internal traffic.
> This issue thus aims to introduce some API or mechanism to flag a Solr node
> as NOT READY for traffic.
--
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
[GitHub] [solr] risdenk commented on a diff in pull request #1407: SOLR-16427: Evaluate and fix errorprone rules - part 5
risdenk commented on code in PR #1407:
URL: https://github.com/apache/solr/pull/1407#discussion_r1151134327
##
solr/solrj/src/java/org/noggit/JSONUtil.java:
##
@@ -17,11 +17,19 @@
package org.noggit;
public class JSONUtil {
+ @SuppressWarnings("MutablePublicArray")
public static final char[] TRUE_CHARS = new char[] {'t', 'r', 'u', 'e'};
+
+ @SuppressWarnings("MutablePublicArray")
public static final char[] FALSE_CHARS = new char[] {'f', 'a', 'l', 's',
'e'};
+
+ @SuppressWarnings("MutablePublicArray")
public static final char[] NULL_CHARS = new char[] {'n', 'u', 'l', 'l'};
+
+ @SuppressWarnings("MutablePublicArray")
public static final char[] HEX_CHARS =
new char[] {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b',
'c', 'd', 'e', 'f'};
+
public static final char VALUE_SEPARATOR = ',';
public static final char NAME_SEPARATOR = ':';
public static final char OBJECT_START = '{';
Review Comment:
addressed and removed the suppresswarnings since it wasn't needed anymore.
--
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] [Created] (SOLR-16723) Http2SolrClient should not use Apache Http client classes
Kevin Risden created SOLR-16723: --- Summary: Http2SolrClient should not use Apache Http client classes Key: SOLR-16723 URL: https://issues.apache.org/jira/browse/SOLR-16723 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Components: SolrJ Reporter: Kevin Risden Assignee: Kevin Risden -- 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-16723) Http2SolrClient should not use Apache Http client classes
[ https://issues.apache.org/jira/browse/SOLR-16723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16723: Description: https://lists.apache.org/thread/vz6gldbdq0gylncpwsoshfvlvns4kqv8 > Http2SolrClient should not use Apache Http client classes > - > > Key: SOLR-16723 > URL: https://issues.apache.org/jira/browse/SOLR-16723 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > > https://lists.apache.org/thread/vz6gldbdq0gylncpwsoshfvlvns4kqv8 -- 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-16723) Http2SolrClient should not use Apache Http client classes
[ https://issues.apache.org/jira/browse/SOLR-16723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16723: Affects Version/s: 9.2 > Http2SolrClient should not use Apache Http client classes > - > > Key: SOLR-16723 > URL: https://issues.apache.org/jira/browse/SOLR-16723 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 9.2 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > > @elyograg pointed out that Http2SolrClient has Apache Http Client class in > use and it shouldn't be needed since Http2SolrClient is Jetty client based. > https://lists.apache.org/thread/vz6gldbdq0gylncpwsoshfvlvns4kqv8 > Based on some digging, this was introduced here - > https://github.com/apache/solr/commit/8efed0555898f485d435d53a72cb6441507d81e1#diff-db379c74efc9ff28acfd7571b07e16dbcdaa510783f2bee835b4a288927b5b3d > It looks like it inadvertently copied from HttpSolrClient.java and used > ContentType.parse(ct).getMimeType() instead of > MimeTypes.getContentTypeWithoutCharset(ct). -- 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-16723) Http2SolrClient should not use Apache Http client classes
[ https://issues.apache.org/jira/browse/SOLR-16723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16723: Description: @elyograg pointed out that Http2SolrClient has Apache Http Client class in use and it shouldn't be needed since Http2SolrClient is Jetty client based. https://lists.apache.org/thread/vz6gldbdq0gylncpwsoshfvlvns4kqv8 Based on some digging, this was introduced here - https://github.com/apache/solr/commit/8efed0555898f485d435d53a72cb6441507d81e1#diff-db379c74efc9ff28acfd7571b07e16dbcdaa510783f2bee835b4a288927b5b3d It looks like it inadvertently copied from HttpSolrClient.java and used ContentType.parse(ct).getMimeType() instead of MimeTypes.getContentTypeWithoutCharset(ct). was: https://lists.apache.org/thread/vz6gldbdq0gylncpwsoshfvlvns4kqv8 > Http2SolrClient should not use Apache Http client classes > - > > Key: SOLR-16723 > URL: https://issues.apache.org/jira/browse/SOLR-16723 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > > @elyograg pointed out that Http2SolrClient has Apache Http Client class in > use and it shouldn't be needed since Http2SolrClient is Jetty client based. > https://lists.apache.org/thread/vz6gldbdq0gylncpwsoshfvlvns4kqv8 > Based on some digging, this was introduced here - > https://github.com/apache/solr/commit/8efed0555898f485d435d53a72cb6441507d81e1#diff-db379c74efc9ff28acfd7571b07e16dbcdaa510783f2bee835b4a288927b5b3d > It looks like it inadvertently copied from HttpSolrClient.java and used > ContentType.parse(ct).getMimeType() instead of > MimeTypes.getContentTypeWithoutCharset(ct). -- 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-16723) Http2SolrClient should not use Apache Http client classes
[ https://issues.apache.org/jira/browse/SOLR-16723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16723: Priority: Minor (was: Major) > Http2SolrClient should not use Apache Http client classes > - > > Key: SOLR-16723 > URL: https://issues.apache.org/jira/browse/SOLR-16723 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 9.2 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Minor > > @elyograg pointed out that Http2SolrClient has Apache Http Client class in > use and it shouldn't be needed since Http2SolrClient is Jetty client based. > https://lists.apache.org/thread/vz6gldbdq0gylncpwsoshfvlvns4kqv8 > Based on some digging, this was introduced here - > https://github.com/apache/solr/commit/8efed0555898f485d435d53a72cb6441507d81e1#diff-db379c74efc9ff28acfd7571b07e16dbcdaa510783f2bee835b4a288927b5b3d > It looks like it inadvertently copied from HttpSolrClient.java and used > ContentType.parse(ct).getMimeType() instead of > MimeTypes.getContentTypeWithoutCharset(ct). -- 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
[GitHub] [solr] risdenk opened a new pull request, #1503: SOLR-16723: Http2SolrClient should not use Apache Http client classes
risdenk opened a new pull request, #1503: URL: https://github.com/apache/solr/pull/1503 https://issues.apache.org/jira/browse/SOLR-16723 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16723) Http2SolrClient should not use Apache Http client classes
[ https://issues.apache.org/jira/browse/SOLR-16723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16723: Status: Patch Available (was: Open) > Http2SolrClient should not use Apache Http client classes > - > > Key: SOLR-16723 > URL: https://issues.apache.org/jira/browse/SOLR-16723 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 9.2 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Minor > > @elyograg pointed out that Http2SolrClient has Apache Http Client class in > use and it shouldn't be needed since Http2SolrClient is Jetty client based. > https://lists.apache.org/thread/vz6gldbdq0gylncpwsoshfvlvns4kqv8 > Based on some digging, this was introduced here - > https://github.com/apache/solr/commit/8efed0555898f485d435d53a72cb6441507d81e1#diff-db379c74efc9ff28acfd7571b07e16dbcdaa510783f2bee835b4a288927b5b3d > It looks like it inadvertently copied from HttpSolrClient.java and used > ContentType.parse(ct).getMimeType() instead of > MimeTypes.getContentTypeWithoutCharset(ct). -- 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-16722) API to flag a solr node NOT READY for requests
[
https://issues.apache.org/jira/browse/SOLR-16722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706151#comment-17706151
]
Jan Høydahl commented on SOLR-16722:
Another obvious option would be for the Solr Operator to simply remove the
{{live_nodes} entry for the node it wants to drain. But I intuitively rejected
it, assuming it would muddy the waters around what {{live_nodes}} means.
I also rejected a thought of attaching a child node or json content to existing
{{live_nodes/foo}} since that would add a need for more watches(?)
> API to flag a solr node NOT READY for requests
> --
>
> Key: SOLR-16722
> URL: https://issues.apache.org/jira/browse/SOLR-16722
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Jan Høydahl
>Priority: Major
>
> Spinoff from solr operator PR
> [https://github.com/apache/solr-operator/issues/529]
> When solr-operator performs a rolling restart or rolling upgrade, it will
> stop one node at a time, but SolrJ (both external and internal) will continue
> sending traffic to the node until requests start failing, since at the time
> SolrJ picks up the "live_nodes" change, it is too late.
> While the operator PR mentioned above will prevent external requests through
> the k8s service to the draining node, it will not prevent internal traffic.
> This issue thus aims to introduce some API or mechanism to flag a Solr node
> as NOT READY for traffic.
--
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
[GitHub] [solr-operator] hmontesdeoca commented on issue #534: Ability to add additional volumes to Zookeeper Pods
hmontesdeoca commented on issue #534: URL: https://github.com/apache/solr-operator/issues/534#issuecomment-1487639416 thank you for the information, I will relay this to my team. -- 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
[GitHub] [solr] noblepaul commented on pull request #1485: SOLR-16507: Remove NodeStateProvider & Snitch
noblepaul commented on PR #1485: URL: https://github.com/apache/solr/pull/1485#issuecomment-1487748631 LGTM , `snitch` must be removed anyway -- 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-16723) Http2SolrClient should not use Apache Http client classes
[ https://issues.apache.org/jira/browse/SOLR-16723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706204#comment-17706204 ] David Smiley commented on SOLR-16723: - SOLR-16079 -- once we modularize the HttpClient based SolrJ SolrClients into its own module, this mistake won't happen. The little change here could even be considered part of that. > Http2SolrClient should not use Apache Http client classes > - > > Key: SOLR-16723 > URL: https://issues.apache.org/jira/browse/SOLR-16723 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 9.2 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > @elyograg pointed out that Http2SolrClient has Apache Http Client class in > use and it shouldn't be needed since Http2SolrClient is Jetty client based. > https://lists.apache.org/thread/vz6gldbdq0gylncpwsoshfvlvns4kqv8 > Based on some digging, this was introduced here - > https://github.com/apache/solr/commit/8efed0555898f485d435d53a72cb6441507d81e1#diff-db379c74efc9ff28acfd7571b07e16dbcdaa510783f2bee835b4a288927b5b3d > It looks like it inadvertently copied from HttpSolrClient.java and used > ContentType.parse(ct).getMimeType() instead of > MimeTypes.getContentTypeWithoutCharset(ct). -- 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-16465) Start the migration of the Admin UI to React
[ https://issues.apache.org/jira/browse/SOLR-16465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706228#comment-17706228 ] Marcus Eagan commented on SOLR-16465: - Thanks [~janhoy] that's helpful. [~gus] regarding your point about learning a new tool. I think it's valid. I'm going to do my best to make that easy for you and others through: * heavy documentation * a video presentation to explain the architecture * discussing with all interested * soliciting and categorizing feedback from the thousands of users for which Solr is a mission-critical component of their respective businesses I'm going to push up some code soon that will be pretty far along. My initial goal is to document and comment it heavily so that the team can understand exactly how things are working to make it easier to extend. As we get further along, I think some of the extraneous comments can comment and the Solr UI will be well-documented in the ref guide. Obviously, even from this step we will be quite a ways off there. I think it should provide a strong starting point for us to truly move the ball forward here. > Start the migration of the Admin UI to React > > > Key: SOLR-16465 > URL: https://issues.apache.org/jira/browse/SOLR-16465 > Project: Solr > Issue Type: Wish > Components: Admin UI >Reporter: Jeb Nix >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > I suggest using > [ngUpgrade|https://angular.io/guide/upgrade#upgrading-with-ngupgrade] to > start a linear migration process to Angular from Angular JS. ngUpgrade will > reach the end of life at the end of 2023, so we will only get a year of using > it seamlessly, but this seems to me like the last resort regarding a linear > migration of the Admin UI codebase. The need for this is of course to migrate > the current Admin UI project to newer technology, instead of writing it all > from the start (or implementing the same stuff once more in YASA). -- 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
