Re: [PR] doc(volumes): add docs for attaching additional volumes [solr-operator]
janhoy commented on PR #739: URL: https://github.com/apache/solr-operator/pull/739#issuecomment-2548384419 Thanks for the contribution. I'm not sure if "Data storage" is the best place to describe custom volume mounts as they are NOT used to store index data but configuration or backup. And `podOptions` is not something that is specific to Solr but to k8s, so perhaps mention in general without any examples that any standard pod option can be configured here, such as volumes. When it comes to configuring Solr for backups, that is already covered by this documentation, for our managed backup feature, I think it will be confusing if we document a different approach as well: https://github.com/apache/solr-operator/tree/3cb870bd4d170390de829683ff4649f37e3a5658/docs/solr-backup -- 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] doc(volumes): add docs for attaching additional volumes [solr-operator]
mcarroll1 commented on PR #739: URL: https://github.com/apache/solr-operator/pull/739#issuecomment-2548715360 Sorry, I mean to link https://github.com/apache/solr-operator/blob/main/config/crd/bases/solr.apache.org_solrclouds.yaml#L7869, which appears to very closely mimic the backup volume CRD. To your point, perhaps this volume example is one specific slice of a very long spec that is mostly just passed onto K8s after some loose adaptation. However, I think it's still a problem that I find myself reading source code here to figure this out. Does the CRD itself produce any output that is accesible from our docs? It seems to be quite well commented. -- 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-17596) Solr 8.11.2 - 9.0 standalone mode nullPointerException when ShardHandlerFactory defined
[ https://issues.apache.org/jira/browse/SOLR-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny updated SOLR-17596: - Description: Same issue as https://issues.apache.org/jira/browse/SOLR-16485 as this was first introduced in version 8.11.2 "Solr fails to create cores with a "NullPointerException" error when "shardHandlerFactory" is defined for any handlers in the solrconfig.xml file." Can we also cut an 8.11.5 version and fix this issue there as well? was: Same issue as https://issues.apache.org/jira/browse/SOLR-16485 "Solr fails to create cores with a "NullPointerException" error when "shardHandlerFactory" is defined for any handlers in the solrconfig.xml file." Can we also cut an 8.11.5 version and fix this issue there as well? > Solr 8.11.2 - 9.0 standalone mode nullPointerException when > ShardHandlerFactory defined > --- > > Key: SOLR-17596 > URL: https://issues.apache.org/jira/browse/SOLR-17596 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.0, 8.11.2, 8.11.3, 8.11.4 >Reporter: Danny >Priority: Major > > Same issue as https://issues.apache.org/jira/browse/SOLR-16485 as this was > first introduced in version 8.11.2 > "Solr fails to create cores with a "NullPointerException" error when > "shardHandlerFactory" is defined for any handlers in the solrconfig.xml file." > > Can we also cut an 8.11.5 version and fix this issue there as well? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17596) Solr 8.11.2 - 9.0 standalone mode nullPointerException when ShardHandlerFactory defined
Danny created SOLR-17596: Summary: Solr 8.11.2 - 9.0 standalone mode nullPointerException when ShardHandlerFactory defined Key: SOLR-17596 URL: https://issues.apache.org/jira/browse/SOLR-17596 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 8.11.4, 8.11.3, 8.11.2, 9.0 Reporter: Danny Same issue as https://issues.apache.org/jira/browse/SOLR-16485 "Solr fails to create cores with a "NullPointerException" error when "shardHandlerFactory" is defined for any handlers in the solrconfig.xml file." Can we also cut an 8.11.5 version and fix this issue there as well? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [I] Mounting a volume to an init container is not clear [solr-operator]
mcarroll1 commented on issue #736: URL: https://github.com/apache/solr-operator/issues/736#issuecomment-2548746117 Turns out you can find the full spec here: https://github.com/apache/solr-operator/blob/main/config/crd/bases/solr.apache.org_solrclouds.yaml#L7038 -- 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-17579: Refactoring suggested by IDE in ReplicationHandler and tests [solr]
epugh commented on code in PR #2893:
URL: https://github.com/apache/solr/pull/2893#discussion_r1888332909
##
solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java:
##
@@ -1532,7 +1518,8 @@ private Long readIntervalNs(String interval) {
public static final String FETCH_FROM_LEADER = "fetchFromLeader";
// in case of TLOG replica, if leaderVersion = zero, don't do commit
- // otherwise updates from current tlog won't copied over properly to the new
tlog, leading to data
+ // otherwise updates from current tlog won't be copied over properly to the
new tlog, leading to
+ // data
// loss
// don't commit on leader version zero for PULL replicas as PULL should only
get its index
Review Comment:
dang it, I trusted `gw tidy` too much..
--
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] doc(volumes): add docs for attaching additional volumes [solr-operator]
mcarroll1 commented on PR #739: URL: https://github.com/apache/solr-operator/pull/739#issuecomment-2548525920 @janhoy I'm happy to move this information and change the example to something like a ConfigMap. Is there anywhere we can add "extended docs/examples" though? I understand not wanting to confuse the main documentation, but this is not exactly vanilla K8s. These volume additions are actually part of the solrcloud CRD: https://github.com/apache/solr-operator/blob/main/config/crd/bases/solr.apache.org_solrclouds.yaml#L1312 In particular, that `source` parameter is a point of confusion. -- 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-17579: Refactoring suggested by IDE in ReplicationHandler and tests [solr]
epugh commented on code in PR #2893: URL: https://github.com/apache/solr/pull/2893#discussion_r1888333804 ## solr/CHANGES.txt: ## @@ -164,7 +164,8 @@ Dependency Upgrades Other Changes - -(No changes) +* SOLR-17579: Remove unused code and other refactorings in ReplicationHandler and tests. Removed unused public Review Comment: i went back and forth on it, since I'd created a JIRA... I then thought, it should then go in Changes...Plus removing a public variable... We do need to add to our dev docs a concise "this is what Changes" is for... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17380) Consolidate Duplicate Unit Tests between ZkSubcommandsTest and SolrCLIZkToolsTest
[ https://issues.apache.org/jira/browse/SOLR-17380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17380. -- Resolution: Abandoned > Consolidate Duplicate Unit Tests between ZkSubcommandsTest and > SolrCLIZkToolsTest > - > > Key: SOLR-17380 > URL: https://issues.apache.org/jira/browse/SOLR-17380 > Project: Solr > Issue Type: Sub-task > Components: cli >Reporter: Eric Pugh >Priority: Minor > > We have written quite a few duplicate tests between these two classes. Go > through and merge them into one set of tests and take the best of both in > terms of assertions and test structure. -- 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-17380) Consolidate Duplicate Unit Tests between ZkSubcommandsTest and SolrCLIZkToolsTest
[ https://issues.apache.org/jira/browse/SOLR-17380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906384#comment-17906384 ] Eric Pugh commented on SOLR-17380: -- Ugh, I took a stab at it, and just not feeling it. I'm going to mark it as abandoned... if someone else with fresh energy grabbed it as a nice opportunity for refactoring, then please re-open! > Consolidate Duplicate Unit Tests between ZkSubcommandsTest and > SolrCLIZkToolsTest > - > > Key: SOLR-17380 > URL: https://issues.apache.org/jira/browse/SOLR-17380 > Project: Solr > Issue Type: Sub-task > Components: cli >Reporter: Eric Pugh >Priority: Minor > > We have written quite a few duplicate tests between these two classes. Go > through and merge them into one set of tests and take the best of both in > terms of assertions and test structure. -- 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-17306: fix replication problem on follower restart [solr]
epugh commented on PR #2874: URL: https://github.com/apache/solr/pull/2874#issuecomment-2548198818 I tried to push latest `main` updates to the branch, but i don't have permissions to push to your branch... Could you update and add a CHANGES.txt entry? Using the "via Eric Pugh" style and then I'll merge and back port. -- 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-17306) Solr Repeater or Slave loses data after restart when replication is not enabled on leader
[
https://issues.apache.org/jira/browse/SOLR-17306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh reassigned SOLR-17306:
Assignee: Eric Pugh
> Solr Repeater or Slave loses data after restart when replication is not
> enabled on leader
> -
>
> Key: SOLR-17306
> URL: https://issues.apache.org/jira/browse/SOLR-17306
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.2, 9.3, 9.4, 9.5, 9.6
>Reporter: Peter Kroiss
>Assignee: Eric Pugh
>Priority: Major
> Labels: pull-request-available
> Attachments: solr-replication-test.txt
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> We are testing Solr 9.6.2 in a leader - repeater - follower configuration. We
> have times where we write the leader heavily, in that time replication is
> disabled to save bandwidth.
> In the time, when replication is disabled on leader, the repeater restarts
> for some reason, the repeater loses all documents and doesn't recover when
> the leader is opened for replication.
> The documents are deleted but indexVersion and generation properties are set
> to the value of the leader, so the repeater or follower doesn't recover when
> the leader is opened for replication again.
> It recovers only when there are commits on the leader after opening the
> replication.
> Log:
> 2024-05-22 06:18:42.186 INFO (qtp16373883-27-null-23) [c: s: r: x:mycore
> t:null-23] o.a.s.c.S.Request webapp=/solr path=/replication
> params=\{wt=json&command=details} status=0 QTime=10
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Leader's generation: 0
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Leader's version: 0
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Follower's generation: 2913
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Follower's version: 1716300697144
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher New index in Leader. Deleting mine...
>
> --> there is no new Index in Leader it is only closed for replication
>
>
> We think the problem is in IndexFetcher
> old: if (IndexDeletionPolicyWrapper.getCommitTimestamp(commit) != 0L) {
> forceReplication - will probably fix the problem
> new : if (forceReplication &&
> IndexDeletionPolicyWrapper.getCommitTimestamp(commit) != 0L) {
>
>
>
>
> When investigation the problem we also found some inconsistencies in the
> details request. There are two fragments leader. When the leader is closed
> for replication the property leader. replicationEnabled is set to true, the
> property follower. leaderDetails. Leader. replicationEnabled is correct.
>
> Example
> curl -s
> "https://solr9-repeater:8983/solr/mycore/replication?wt=json&command=details";
> | jq '.details |
> { indexSize: .indexSize, indexVersion: .indexVersion, generation:
> .generation, indexPath: .indexPath, leader: \\{ replicableVersion:
> .leader.replicableVersion, replicableGeneration:
> .leader.replicableGeneration, replicationEnabled: .leader.replicationEnabled }
> ,
> follower: { leaderDetails: { indexSize: .follower.leaderDetails.indexSize,
> generation: .follower.leaderDetails.generation,
> indexVersion: .follower.leaderDetails.indexVersion, indexPath:
> .follower.leaderDetails.indexPath,
> leader:
> { replicableVersion: .follower.leaderDetails.leader.replicableVersion ,
> replicableGeneration: .follower.leaderDetails.leader.replicableGeneration,
> replicationEnabled: .follower.leaderDetails.leader.replicationEnabled }
> }}
> }'
>
> {
> "indexSize": "10.34 GB",
> "indexVersion": 1716358708159,
> "generation": 2913,
> "indexPath": "/var/solr/data/mycore/data/index.20240522061946262",
> "leader":
> { "replicableVersion": 1716358708159, "replicableGeneration": 2913,
> "replicationEnabled": "true" }
> ,
> "follower": {
> "leaderDetails": {
> "indexSize": "10.34 GB",
> "generation": 2913,
> "indexVersion": 1716358708159,
> "indexPath": "/var/solr/data/mycore/data/restore.20240508131046932",
> "leader":
> { "replicableVersion": 1716358708159, "replicableGeneration":
> 2913, "replicationEnabled": "false" }
> }
> }
> }
--
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] doc(volumes): add docs for attaching additional volumes [solr-operator]
janhoy commented on PR #739: URL: https://github.com/apache/solr-operator/pull/739#issuecomment-2548641395 > These volume additions are actually part of the solrcloud CRD The `customSolrKubeOptions.podOptions` that this PR is about is just passed on to k8s. The link you just provided refers to the custom `backupRepositories` feature of the CRD, which offers to manage a backup volume for you. This is documented in the `SolrBackup` CRD docs. I don't know where in the main `SolrClouds` doc to give more info about what you can do with `podOptions`. I think it should be enough to refer to k8s docs and mention that you can mount volumes etc. The default `values.yaml` also has some placeholder and comments as to what you can put below `podOptions`. -- 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] Reformat comment better [solr]
epugh merged PR #2910: URL: https://github.com/apache/solr/pull/2910 -- 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-17595) CLI examples are broken on Windows
[ https://issues.apache.org/jira/browse/SOLR-17595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906435#comment-17906435 ] ASF subversion and git services commented on SOLR-17595: Commit a4229e76771da0125b38204db01ea0934e09c4f4 in solr's branch refs/heads/main from Christos Malliaridis [ https://gitbox.apache.org/repos/asf?p=solr.git;h=a4229e76771 ] SOLR-17595: Fix Solr examples for Windows (#2909) * Fix argument parsing for -D options with multiple values on Windows * Fix invalid usage of wildcards in RunExampleTool / PostTool > CLI examples are broken on Windows > -- > > Key: SOLR-17595 > URL: https://issues.apache.org/jira/browse/SOLR-17595 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: cli, examples, SolrCLI >Affects Versions: 9.7 >Reporter: Christos Malliaridis >Assignee: Christos Malliaridis >Priority: Blocker > Labels: cli, pull-request-available > Fix For: 9.8 > > Attachments: console-output-9.7.txt, console-output.txt > > Time Spent: 0.5h > Remaining Estimate: 0h > > When trying to run the examples on Windows, it fails with an unspecified > error. I have attached the output for investigation. Bug is present in latest > changes. > A previous state was reporting more details about a potential cause. It was > mentioning the "*/xml" in in RunExampleTool.java, but that may not be anymore > the issue for the current failure (but could be a lead for the error). > The error is slightly different in the branches main, 9x and 9.8. -- 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-17595: Fix Solr examples for Windows [solr]
malliaridis merged PR #2909: URL: https://github.com/apache/solr/pull/2909 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[PR] SOLR-17595: Backport "Fix Solr examples for Windows" [solr]
malliaridis opened a new pull request, #2911: URL: https://github.com/apache/solr/pull/2911 https://issues.apache.org/jira/browse/SOLR-17595 # Description This is the backport for the fixes from #2909. # Checklist Please review the following and check all that apply: - X] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [X] I have created a Jira issue and added the issue ID to my pull request title. - [X] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation) - [ ] I have developed this patch against the `main` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16909) Collections LIST command should fetch ZK data, not cached state
[ https://issues.apache.org/jira/browse/SOLR-16909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906616#comment-17906616 ] David Smiley commented on SOLR-16909: - BTW the perf benefit is O(collections) assuming more than one node. Single node cluster would see no benefit as it'd be watching all collections. > Collections LIST command should fetch ZK data, not cached state > --- > > Key: SOLR-16909 > URL: https://issues.apache.org/jira/browse/SOLR-16909 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: David Smiley >Priority: Major > > The LIST command to the Collections API presently returns all collections > from the cached ClusterState. The proposal here is to fetch the child nodes > in ZooKeeper instead. While the distinction is minor, the intent is to > improve robustness / comprehensiveness. It may mean a collection is listed > that is being created or being deleted that otherwise might not have been > returned. The scenario driving this is to facilitate cleanup daemons that > identify potentially left-over data from a collection creation or deletion > that maybe failed (partial create or delete). -- 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-17541: LBSolrClient implementations should agree on 'getClient()' semantics [solr]
jdyer1 commented on code in PR #2899:
URL: https://github.com/apache/solr/pull/2899#discussion_r1889342889
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudHttp2SolrClient.java:
##
@@ -404,23 +400,6 @@ public Builder withCollectionCacheTtl(long timeToLive,
TimeUnit unit) {
return this;
}
-/**
- * Set the internal http client.
- *
- * Note: closing the httpClient instance is at the responsibility of
the caller.
- *
- * @param httpClient http client
- * @return this
- */
-public Builder withHttpClient(Http2SolrClient httpClient) {
Review Comment:
This is the most controversial part of this PR, and I do not want to merge a
potentially disruptive API change like this without buy-in. I do not think
this is much of a burden though, ecause the Builder has
`withInternalClientBuilder`, which users should be able to easily migrate to
use.
The purpose of forcing this is that `CloudHttp2SolrClient` in turn passes
this Client(Builder) to `LBHttp2SolrClient`. But as noted before,
`LBHttp2SolrClient` doesn't really use this client either; it clones it using
`Http2SolrClient.builder#withHttpClient`. Yet we've made `LBHttp2SolrClient`
generic so this means that any subclass of `HttpSolrClientBase` needs to also
have a way to be cloned. Personally I think clone methods like this are
brittle and a maintenance burden, and I don't want to need to write one for
`HttpJdkSolrClient`. It also seems like a better API: by telling the user we
want a Builder, we signal that we will create Clients as needed. Passing in an
already-built Client signals that we will use that particular one, which is not
always the case here.
--
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-17541: LBSolrClient implementations should agree on 'getClient()' semantics [solr]
jdyer1 commented on code in PR #2899:
URL: https://github.com/apache/solr/pull/2899#discussion_r1889342889
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudHttp2SolrClient.java:
##
@@ -404,23 +400,6 @@ public Builder withCollectionCacheTtl(long timeToLive,
TimeUnit unit) {
return this;
}
-/**
- * Set the internal http client.
- *
- * Note: closing the httpClient instance is at the responsibility of
the caller.
- *
- * @param httpClient http client
- * @return this
- */
-public Builder withHttpClient(Http2SolrClient httpClient) {
Review Comment:
This is the most controversial part of this PR, and I do not want to merge a
potentially disruptive API change like this without buy-in. I do not think
this is much of a burden though, because the Builder has
`withInternalClientBuilder`, which users should be able to easily migrate to
use.
The purpose of forcing this is that `CloudHttp2SolrClient` in turn passes
this Client(Builder) to `LBHttp2SolrClient`. But as noted before,
`LBHttp2SolrClient` doesn't really use this Client either; it clones it using
`Http2SolrClient.builder#withHttpClient`. Yet we've made `LBHttp2SolrClient`
generic so this means that any subclass of `HttpSolrClientBase` needs to also
have a way to be cloned. Personally I think clone methods like this are
brittle and a maintenance burden, and I don't want to need to write one for
`HttpJdkSolrClient`. It also seems like a better API: by telling the user we
want a Builder, we signal that we will create Clients as needed. Passing in an
already-built Client signals that we will use that particular one, which is not
always the case here.
--
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-17541: LBSolrClient implementations should agree on 'getClient()' semantics [solr]
dsmiley commented on code in PR #2899:
URL: https://github.com/apache/solr/pull/2899#discussion_r1889609307
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudHttp2SolrClient.java:
##
@@ -404,23 +400,6 @@ public Builder withCollectionCacheTtl(long timeToLive,
TimeUnit unit) {
return this;
}
-/**
- * Set the internal http client.
- *
- * Note: closing the httpClient instance is at the responsibility of
the caller.
- *
- * @param httpClient http client
- * @return this
- */
-public Builder withHttpClient(Http2SolrClient httpClient) {
Review Comment:
> it clones it using Http2SolrClient.builder#withHttpClient
which still exists, so if a user somehow has a client but not a builder but
needs one due to the API change you introduce, they have this option.
> by telling the user we want a Builder, we signal that we will create
Clients as needed
Well written James!
+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
Re: [PR] SOLR-17541: LBSolrClient implementations should agree on 'getClient()' semantics [solr]
dsmiley commented on code in PR #2899:
URL: https://github.com/apache/solr/pull/2899#discussion_r1889609800
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttp2SolrClient.java:
##
@@ -94,35 +97,63 @@
*
* @since solr 8.0
*/
-public class LBHttp2SolrClient extends
LBSolrClient {
+public class LBHttp2SolrClient>
extends LBSolrClient {
Review Comment:
in another PR then.
--
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-17541: LBSolrClient implementations should agree on 'getClient()' semantics [solr]
jdyer1 commented on code in PR #2899:
URL: https://github.com/apache/solr/pull/2899#discussion_r1889352673
##
solr/core/src/java/org/apache/solr/security/HttpClientBuilderPlugin.java:
##
@@ -34,4 +34,8 @@ public interface HttpClientBuilderPlugin {
public SolrHttpClientBuilder getHttpClientBuilder(SolrHttpClientBuilder
builder);
public default void setup(Http2SolrClient client) {}
+
+ public default void setup(Http2SolrClient.Builder httpClientBuilder,
Http2SolrClient client) {
Review Comment:
Yes, I agree separate methods would be nicer. But the implementing classes
do things on `setup` that should only be done once. I settled on this ugly
API with hopes this is the least-trappy thing to leave for future developers.
--
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-17541: LBSolrClient implementations should agree on 'getClient()' semantics [solr]
jdyer1 commented on code in PR #2899:
URL: https://github.com/apache/solr/pull/2899#discussion_r1889354976
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttp2SolrClient.java:
##
@@ -94,35 +97,63 @@
*
* @since solr 8.0
*/
-public class LBHttp2SolrClient extends
LBSolrClient {
+public class LBHttp2SolrClient>
extends LBSolrClient {
Review Comment:
I worry too I have gone down the wrong road with this. On the other hand, I
do not want consider this with this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17541: LBSolrClient implementations should agree on 'getClient()' semantics [solr]
jdyer1 commented on PR #2899: URL: https://github.com/apache/solr/pull/2899#issuecomment-2549882911 > So this would be Solr 10? Yes. When I read the description on this ticket, it seemed to me a good opportunity to improve our API with the upcoming major release. It seems wrong we clone the passed-in client. This is especially important if we want to eventually have merely one LB Client, one Cloud Client and one Cluster State Provider that can take any subclass of `HttpSolrClientBase`. -- 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-17541: LBSolrClient implementations should agree on 'getClient()' semantics [solr]
dsmiley commented on code in PR #2899:
URL: https://github.com/apache/solr/pull/2899#discussion_r1889612751
##
solr/core/src/java/org/apache/solr/security/PKIAuthenticationPlugin.java:
##
@@ -374,8 +374,17 @@ PublicKey fetchPublicKeyFromRemote(String nodename) {
}
}
+ @Override
+ public void setup(Http2SolrClient.Builder httpClientBuilder, Http2SolrClient
client) {
+setup(client, httpClientBuilder);
+ }
+
@Override
public void setup(Http2SolrClient client) {
+setup(client, null);
+ }
+
+ private void setup(Http2SolrClient client, Http2SolrClient.Builder builder) {
Review Comment:
why have this separate and with different parameter order? In other words,
lets make *this* one the `@Override` with builder then client. Remove the 4
lines earlier on 377.
##
solr/core/src/java/org/apache/solr/security/HttpClientBuilderPlugin.java:
##
@@ -34,4 +34,8 @@ public interface HttpClientBuilderPlugin {
public SolrHttpClientBuilder getHttpClientBuilder(SolrHttpClientBuilder
builder);
public default void setup(Http2SolrClient client) {}
+
+ public default void setup(Http2SolrClient.Builder httpClientBuilder,
Http2SolrClient client) {
Review Comment:
Can you point me at such so I can appreciate the problem better?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17596) Solr 8.11.2 - 9.0 standalone mode nullPointerException when ShardHandlerFactory defined
[ https://issues.apache.org/jira/browse/SOLR-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906470#comment-17906470 ] Danny commented on SOLR-17596: -- Ah! Sorry I will go ahead and do that now. Does it matter if the existing issue is closed? > Solr 8.11.2 - 9.0 standalone mode nullPointerException when > ShardHandlerFactory defined > --- > > Key: SOLR-17596 > URL: https://issues.apache.org/jira/browse/SOLR-17596 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.0, 8.11.2, 8.11.3, 8.11.4 >Reporter: Danny >Priority: Major > > Same issue as https://issues.apache.org/jira/browse/SOLR-16485 as this was > first introduced in version 8.11.2 > "Solr fails to create cores with a "NullPointerException" error when > "shardHandlerFactory" is defined for any handlers in the solrconfig.xml file." > > Can we also cut an 8.11.5 version and fix this issue there as well? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16485) Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined
[
https://issues.apache.org/jira/browse/SOLR-16485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906471#comment-17906471
]
Danny commented on SOLR-16485:
--
Seeing how this was introduced in 8.11.2 can this be back ported to 8.11?
Please and thank you.
> Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined
>
>
> Key: SOLR-16485
> URL: https://issues.apache.org/jira/browse/SOLR-16485
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.0
> Environment: Kubernetes using solr-operator 0.6.0
>Reporter: Nick Vladiceanu
>Assignee: Houston Putman
>Priority: Major
> Fix For: 9.1, main (10.0)
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {color:#00} Solr fails to create cores with a “NullPointerException"
> error when “shardHandlerFactory” is defined for any handlers in the
> solrconfig.xml file.{color}
> *Snippet from solrconfig.xml:*
> {code:java}
> class="HttpShardHandlerFactory">
> ${socketTimeout:800}
> ${connTimeout:500}
>
> {code}
> *Snippet of NullPointerException*{color:#00} (full text here:
> {color}[https://justpaste.it/5lntq]{color:#00} ):{color}
> {color:#00}o{color}
> {code:java}
> lxeu-atlas-web-dist-solr-1 | Caused by: java.lang.NullPointerException
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.handler.component.HttpShardHandlerFactory.setSecurityBuilder(HttpShardHandlerFactory.java:299)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.handler.component.SearchHandler.inform(SearchHandler.java:185)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:722)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrCore.(SolrCore.java:1155) ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrCore.(SolrCore.java:1048) ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1560)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.CoreContainer.lambda$load$10(CoreContainer.java:950)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202)
> ~[metrics-core-4.1.5.jar:4.1.5]{code}
> {*}Steps{*}{color:#00}:{color}
> {color:#00}1. Run library/solr:9.0.0 in docker (default config, no
> tunings); mount a volume with solrconfig.xml that contains
> shardHandlerFactory and schema.xml;{color}
> {color:#00}2. Create a core using the solrconfig.xml:
> {color}[http://localhost:8983/solr/admin/cores?action=CREATE&name=test&instanceDir=/var/solr/data/test&config=solrconfig.xml&dataDir=data/]
> 3. Failure with nullPointerException;
> 4. Remove the shardHandlerFactory block;
> 5. Repeat step 2;
> 6. Success.
>
> Works fine when running Solr in SolrCloud mode.
> Works fine in Solr 8.11 and all older versions in both, standalone and
> SolrCloud.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Closed] (SOLR-17596) Solr 8.11.2 - 9.0 standalone mode nullPointerException when ShardHandlerFactory defined
[ https://issues.apache.org/jira/browse/SOLR-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny closed SOLR-17596. > Solr 8.11.2 - 9.0 standalone mode nullPointerException when > ShardHandlerFactory defined > --- > > Key: SOLR-17596 > URL: https://issues.apache.org/jira/browse/SOLR-17596 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.0, 8.11.2, 8.11.3, 8.11.4 >Reporter: Danny >Priority: Major > > Same issue as https://issues.apache.org/jira/browse/SOLR-16485 as this was > first introduced in version 8.11.2 > "Solr fails to create cores with a "NullPointerException" error when > "shardHandlerFactory" is defined for any handlers in the solrconfig.xml file." > > Can we also cut an 8.11.5 version and fix this issue there as well? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-15781: Modify v2 `GET /collections/collName` to support full ColStatus response [solr]
gerlowskija commented on PR #2912: URL: https://github.com/apache/solr/pull/2912#issuecomment-2549527042 re: impotent COLSTATUS boolean flags previously discussed [here](https://github.com/apache/solr/pull/2912#issuecomment-2548874545) I think I understand this a bit better now. The ref-guide docs for COLSTATUS describe each of the boolean flags as being independent of one another: `segments` returns base segment data, `fieldInfo` returns detailed information about each indexed field, etc. But in reality on main/branch_9x currently, the flags are dependent on one another. `fieldInfo` and `sizeInfo` have no impact unless paired with `segments=true`. And `segments=true` has no impact on its own either. The ref-guide coverage here doesn't suggest that this is intentional in any way, so I suspect this is a bug that eluded @sigram when he first did SOLR-13292. (Hopefully AB can confirm his intentions if he catches this notification!) Working on that theory, I'll bundle a fix for COLSTATUS into this PR and add some extra tests if there aren't any objections? -- 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-16485) Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined
[
https://issues.apache.org/jira/browse/SOLR-16485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906525#comment-17906525
]
David Smiley commented on SOLR-16485:
-
This should have been back-ported; it's sad it was forgotten. Even if someone
does now, there will be no more official 8.x releases of Solr -- [see this news
announcement|https://solr.apache.org/news.html#solr-8-reaches-end-of-life]. We
decided this recently because it's too burdensome to do 8.x releases at this
point.
> Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined
>
>
> Key: SOLR-16485
> URL: https://issues.apache.org/jira/browse/SOLR-16485
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.0
> Environment: Kubernetes using solr-operator 0.6.0
>Reporter: Nick Vladiceanu
>Assignee: Houston Putman
>Priority: Major
> Fix For: 9.1, main (10.0)
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {color:#00} Solr fails to create cores with a “NullPointerException"
> error when “shardHandlerFactory” is defined for any handlers in the
> solrconfig.xml file.{color}
> *Snippet from solrconfig.xml:*
> {code:java}
> class="HttpShardHandlerFactory">
> ${socketTimeout:800}
> ${connTimeout:500}
>
> {code}
> *Snippet of NullPointerException*{color:#00} (full text here:
> {color}[https://justpaste.it/5lntq]{color:#00} ):{color}
> {color:#00}o{color}
> {code:java}
> lxeu-atlas-web-dist-solr-1 | Caused by: java.lang.NullPointerException
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.handler.component.HttpShardHandlerFactory.setSecurityBuilder(HttpShardHandlerFactory.java:299)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.handler.component.SearchHandler.inform(SearchHandler.java:185)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:722)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrCore.(SolrCore.java:1155) ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrCore.(SolrCore.java:1048) ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1560)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.CoreContainer.lambda$load$10(CoreContainer.java:950)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202)
> ~[metrics-core-4.1.5.jar:4.1.5]{code}
> {*}Steps{*}{color:#00}:{color}
> {color:#00}1. Run library/solr:9.0.0 in docker (default config, no
> tunings); mount a volume with solrconfig.xml that contains
> shardHandlerFactory and schema.xml;{color}
> {color:#00}2. Create a core using the solrconfig.xml:
> {color}[http://localhost:8983/solr/admin/cores?action=CREATE&name=test&instanceDir=/var/solr/data/test&config=solrconfig.xml&dataDir=data/]
> 3. Failure with nullPointerException;
> 4. Remove the shardHandlerFactory block;
> 5. Repeat step 2;
> 6. Success.
>
> Works fine when running Solr in SolrCloud mode.
> Works fine in Solr 8.11 and all older versions in both, standalone and
> SolrCloud.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[PR] SOLR-15781: Modify v2 `GET /collections/collName` to support full ColStatus response [solr]
gerlowskija opened a new pull request, #2912: URL: https://github.com/apache/solr/pull/2912 https://issues.apache.org/jira/browse/SOLR-15781 # Description Solr's v1 "/admin/collections?action=COLSTATUS" API is a useful way to get a high level summary of a single collection. This includes the collection status and metadata (which CLUSTERSTATUS also returns) as well as very detailed data core-level data about fields, disk-usage, etc. The v2 API lacks all of this functionality. # Solution This PR addresses this by modifying the existing v2 `GET /collections/collName` API to incorporate the v1 "colstatus" functionality. (Previously this v2 endpoint returned the same response as v1's /admin/collections?action=CLUSTERSTATUS&collection=collName`) The PR also converts this endpoint to JAX-RS in the process, so that it's included in our OAS and codegen. # Tests Added test in CollectionsAPISolrJTest that makes use of the OAS-generated SolrJ request/response. Existing tests continue to pass. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation) - [x] I have developed this patch against the `main` branch. - [x] I have run `./gradlew check`. - [x] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-15781: Modify v2 `GET /collections/collName` to support full ColStatus response [solr]
dsmiley commented on code in PR #2912:
URL: https://github.com/apache/solr/pull/2912#discussion_r165754
##
solr/api/src/java/org/apache/solr/client/api/model/CollectionStatusResponse.java:
##
@@ -0,0 +1,164 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.client.api.model;
+
+import com.fasterxml.jackson.annotation.JsonProperty;
+import java.util.List;
+import java.util.Map;
+
+/** Response of the CollectionStatusApi.getCollectionStatus() API */
+public class CollectionStatusResponse extends SolrJerseyResponse {
+
+ @JsonProperty public String name;
+ @JsonProperty public Integer znodeVersion;
+ @JsonProperty public Long creationTimeMillis;
+ @JsonProperty public CollectionMetadata properties;
+ @JsonProperty public Integer activeShards;
+ @JsonProperty public Integer inactiveShards;
+ @JsonProperty public List schemaNonCompliant;
+
+ @JsonProperty public Map shards;
+
+ // Always present in response
+ public static class CollectionMetadata {
+@JsonProperty public String configName;
+@JsonProperty public Integer nrtReplicas;
+@JsonProperty public Integer pullReplicas;
+@JsonProperty public Integer tlogReplicas;
+@JsonProperty public Map router;
+@JsonProperty public Integer replicationFactor;
+ }
+
+ // Always present in response
+ public static class ShardMetadata {
+@JsonProperty public String state; // TODO Make this an enum?
+@JsonProperty public String range;
+@JsonProperty public ReplicaSummary replicas;
+@JsonProperty public LeaderSummary leader;
+ }
+
+ // ALways present in response
+ public static class ReplicaSummary {
+@JsonProperty public Integer total;
+@JsonProperty public Integer active;
+@JsonProperty public Integer down;
+@JsonProperty public Integer recovering;
+
+@JsonProperty("recovery_failed")
+public Integer recoveryFailed;
+ }
+
+ // Always present in response unless otherwise specified
+ public static class LeaderSummary {
+@JsonProperty public String coreNode;
+@JsonProperty public String core;
+@JsonProperty public Boolean leader;
+
+@JsonProperty("node_name")
+public String nodeName;
+
+@JsonProperty("base_url")
+public String baseUrl;
+
+@JsonProperty public String state; // TODO Make this an enum?
+@JsonProperty public String type; // TODO Make this an enum?
+
+@JsonProperty("force_set_state")
+public Boolean forceSetState;
+
+// Present with coreInfo=true || sizeInfo=true unless otherwise specified
+@JsonProperty public SegmentInfo segInfos;
+ }
+
+ // Present with coreInfo=true || sizeInfo=true unless otherwise specified
+ public static class SegmentInfo {
+// Present with coreInfo=true || sizeInfo=true unless otherwise specified
+@JsonProperty public SegmentSummary info;
+
+// Present with rawSize=true
+@JsonProperty public RawSize rawSize;
+
+// Present with fieldInfo=truethis seems pretty useless in isolation?
Is it maybe a bad
+// param name?
+@JsonProperty public List fieldInfoLegend;
+ }
+
+ // Present with rawSize=true unless otherwise specified
+ public static class RawSize {
+@JsonProperty public Map fieldsBySize;
+@JsonProperty public Map typesBySize;
+
+// Present with rawSizeDetails=true
+@JsonProperty public Object details;
+
+// Present with rawSizeSummary=true
+@JsonProperty public Map summary;
+ }
+
+ // Present with coreInfo=true || sizeInfo=true unless otherwise specified
+ public static class SegmentSummary {
+@JsonProperty public String minSegmentLuceneVersion;
+@JsonProperty public String commitLuceneVersion;
+@JsonProperty public Integer numSegments;
+@JsonProperty public String segmentsFileName;
+@JsonProperty public Integer totalMaxDoc;
+
+@JsonProperty
+public Map
+userData; // Typically keys are 'commitCommandVer' and 'commitTimeMSec'
Review Comment:
nit: comment at EOL is awkward for the line wrap; maybe just put before
instead. Or leave as-is of course :-)
##
solr/api/src/java/org/apache/solr/client/api/model/CollectionStatusResponse.java:
##
@@ -0,0 +1,164 @@
+/*
+ * Licensed to the A
[jira] [Commented] (SOLR-17596) Solr 8.11.2 - 9.0 standalone mode nullPointerException when ShardHandlerFactory defined
[ https://issues.apache.org/jira/browse/SOLR-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906474#comment-17906474 ] David Smiley commented on SOLR-17596: - No. > Solr 8.11.2 - 9.0 standalone mode nullPointerException when > ShardHandlerFactory defined > --- > > Key: SOLR-17596 > URL: https://issues.apache.org/jira/browse/SOLR-17596 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.0, 8.11.2, 8.11.3, 8.11.4 >Reporter: Danny >Priority: Major > > Same issue as https://issues.apache.org/jira/browse/SOLR-16485 as this was > first introduced in version 8.11.2 > "Solr fails to create cores with a "NullPointerException" error when > "shardHandlerFactory" is defined for any handlers in the solrconfig.xml file." > > Can we also cut an 8.11.5 version and fix this issue there as well? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17596) Solr 8.11.2 - 9.0 standalone mode nullPointerException when ShardHandlerFactory defined
[ https://issues.apache.org/jira/browse/SOLR-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906494#comment-17906494 ] Danny commented on SOLR-17596: -- Awesome! I added a comment to the existing issue. Thanks for your help. > Solr 8.11.2 - 9.0 standalone mode nullPointerException when > ShardHandlerFactory defined > --- > > Key: SOLR-17596 > URL: https://issues.apache.org/jira/browse/SOLR-17596 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.0, 8.11.2, 8.11.3, 8.11.4 >Reporter: Danny >Priority: Major > > Same issue as https://issues.apache.org/jira/browse/SOLR-16485 as this was > first introduced in version 8.11.2 > "Solr fails to create cores with a "NullPointerException" error when > "shardHandlerFactory" is defined for any handlers in the solrconfig.xml file." > > Can we also cut an 8.11.5 version and fix this issue there as well? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16485) Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined
[
https://issues.apache.org/jira/browse/SOLR-16485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906471#comment-17906471
]
Danny edited comment on SOLR-16485 at 12/17/24 6:21 PM:
Seeing how this was introduced in 8.11.2 can this be back ported to 8.11.5?
Please and thank you.
was (Author: JIRAUSER308140):
Seeing how this was introduced in 8.11.2 can this be back ported to 8.11?
Please and thank you.
> Solr 9 standalone mode nullPointerException when ShardHandlerFactory defined
>
>
> Key: SOLR-16485
> URL: https://issues.apache.org/jira/browse/SOLR-16485
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.0
> Environment: Kubernetes using solr-operator 0.6.0
>Reporter: Nick Vladiceanu
>Assignee: Houston Putman
>Priority: Major
> Fix For: 9.1, main (10.0)
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {color:#00} Solr fails to create cores with a “NullPointerException"
> error when “shardHandlerFactory” is defined for any handlers in the
> solrconfig.xml file.{color}
> *Snippet from solrconfig.xml:*
> {code:java}
> class="HttpShardHandlerFactory">
> ${socketTimeout:800}
> ${connTimeout:500}
>
> {code}
> *Snippet of NullPointerException*{color:#00} (full text here:
> {color}[https://justpaste.it/5lntq]{color:#00} ):{color}
> {color:#00}o{color}
> {code:java}
> lxeu-atlas-web-dist-solr-1 | Caused by: java.lang.NullPointerException
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.handler.component.HttpShardHandlerFactory.setSecurityBuilder(HttpShardHandlerFactory.java:299)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.handler.component.SearchHandler.inform(SearchHandler.java:185)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:722)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrCore.(SolrCore.java:1155) ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.SolrCore.(SolrCore.java:1048) ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1560)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> org.apache.solr.core.CoreContainer.lambda$load$10(CoreContainer.java:950)
> ~[?:?]
> olxeu-atlas-web-dist-solr-1 | at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202)
> ~[metrics-core-4.1.5.jar:4.1.5]{code}
> {*}Steps{*}{color:#00}:{color}
> {color:#00}1. Run library/solr:9.0.0 in docker (default config, no
> tunings); mount a volume with solrconfig.xml that contains
> shardHandlerFactory and schema.xml;{color}
> {color:#00}2. Create a core using the solrconfig.xml:
> {color}[http://localhost:8983/solr/admin/cores?action=CREATE&name=test&instanceDir=/var/solr/data/test&config=solrconfig.xml&dataDir=data/]
> 3. Failure with nullPointerException;
> 4. Remove the shardHandlerFactory block;
> 5. Repeat step 2;
> 6. Success.
>
> Works fine when running Solr in SolrCloud mode.
> Works fine in Solr 8.11 and all older versions in both, standalone and
> SolrCloud.
--
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-17596) Solr 8.11.2 - 9.0 standalone mode nullPointerException when ShardHandlerFactory defined
[ https://issues.apache.org/jira/browse/SOLR-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-17596. - Resolution: Invalid This JIRA issue is a duplicate (and you know that). Instead, ask on the existing issue to back-port. > Solr 8.11.2 - 9.0 standalone mode nullPointerException when > ShardHandlerFactory defined > --- > > Key: SOLR-17596 > URL: https://issues.apache.org/jira/browse/SOLR-17596 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.0, 8.11.2, 8.11.3, 8.11.4 >Reporter: Danny >Priority: Major > > Same issue as https://issues.apache.org/jira/browse/SOLR-16485 as this was > first introduced in version 8.11.2 > "Solr fails to create cores with a "NullPointerException" error when > "shardHandlerFactory" is defined for any handlers in the solrconfig.xml file." > > Can we also cut an 8.11.5 version and fix this issue there as well? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-15781: Modify v2 `GET /collections/collName` to support full ColStatus response [solr]
epugh commented on PR #2912: URL: https://github.com/apache/solr/pull/2912#issuecomment-2548874545 If you think there are parameters that maybe don't make sense going forward, I would vote for skipping them. Get this in, and then see if folks highlight legit use cases for why they need those. If you blindly carry them forward, well, then, we probably are stuck with them foreverIt's easier to add them later then it is to remove them... ;-).Also, we should think about YAGNI more. -- 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-15781) Make v2 APIs more REST-ful and migrate to JAX-RS
[ https://issues.apache.org/jira/browse/SOLR-15781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-15781: -- Labels: V2 pull-request-available (was: V2) > Make v2 APIs more REST-ful and migrate to JAX-RS > > > Key: SOLR-15781 > URL: https://issues.apache.org/jira/browse/SOLR-15781 > Project: Solr > Issue Type: Improvement > Components: v2 API >Reporter: Jason Gerlowski >Priority: Major > Labels: V2, pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > While the v2 API is in many ways an improvement over v1 in terms of > readability and API best practices, it still has a lot of room for > improvement. The recent "experimental" designation for v2 opens the door to > pursuing many of these improvements. > This ticket is intended as an umbrella to track resolution of some of the > known warts in the current v2 API and some of the improvements that can be > made in terms of being more RESTful, etc. > While we're touching the API code for these endpoints, it makes sense to > convert them to JAX-RS as well. This JAX-RS migration work was initially > covered in a separate ticket (see SOLR-16370), but the changes required ended > up overlapping with the "cosmetic-improvement" effort here so significantly > that it made sense to track them together. -- 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-15781: Modify v2 `GET /collections/collName` to support full ColStatus response [solr]
gerlowskija commented on PR #2912: URL: https://github.com/apache/solr/pull/2912#issuecomment-2548920411 > If you blindly carry them forward, well, then, we probably are stuck with them forever Definitely don't want that. But I also don't have too much trust in my very quick-and-dirty manual testing -- that's really all I have saying that the params don't do much. Gonna do more spelunking and then we can figure out what direction to go in. -- 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
