[GitHub] [solr] dsmiley commented on a diff in pull request #1513: SOLR-15703: replace all SolrException.log usage in Solr to just call log.error(...) directly
dsmiley commented on code in PR #1513:
URL: https://github.com/apache/solr/pull/1513#discussion_r1155056589
##
solr/core/src/java/org/apache/solr/core/ZkContainer.java:
##
@@ -219,10 +219,10 @@ public void registerInZk(final SolrCore core, boolean
background, boolean skipRe
} catch (InterruptedException e) {
// Restore the interrupted status
Thread.currentThread().interrupt();
- SolrException.log(log, "", e);
+ log.error("", e);
Review Comment:
```suggestion
log.error("Interrupted", e);
```
BTW I don't get why we had all these logs with empty strings. On the
consuming side as a user, it's weird to see when these exceptions happen.
##
solr/core/src/java/org/apache/solr/core/ZkContainer.java:
##
@@ -233,7 +233,7 @@ public void registerInZk(final SolrCore core, boolean
background, boolean skipRe
} catch (Exception e1) {
log.error("", e1);
}
- SolrException.log(log, "", e);
+ log.error("", e);
Review Comment:
```suggestion
log.error(e.toString(), e);
```
##
solr/core/src/java/org/apache/solr/core/ZkContainer.java:
##
@@ -219,10 +219,10 @@ public void registerInZk(final SolrCore core, boolean
background, boolean skipRe
} catch (InterruptedException e) {
// Restore the interrupted status
Thread.currentThread().interrupt();
- SolrException.log(log, "", e);
+ log.error("", e);
} catch (KeeperException e) {
- SolrException.log(log, "", e);
-} catch (AlreadyClosedException e) {
+ log.error("", e);
Review Comment:
```suggestion
log.error("KeeperException", e);
```
--
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] MarcusSorealheis commented on pull request #1479: SOLR-16465: Replace Login w/ React App
MarcusSorealheis commented on PR #1479: URL: https://github.com/apache/solr/pull/1479#issuecomment-1492824628 As is the nature of these things, I need to blow away a lot of the work to take a different approach. As I mentioned before, it had been a while since I dusted off my JS chops. Looks like Create React Aoo has died after many years being the scaffolding leader. I'm going to take a new approach and I'm sure developers will be enthusiastic to work with the new framework and approach I will push up in a bit. -- 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] dsmiley commented on a diff in pull request #1501: SOLR-16713: Replace Guava usages with pure Java (part 2)
dsmiley commented on code in PR #1501:
URL: https://github.com/apache/solr/pull/1501#discussion_r1155050465
##
solr/solrj/src/java/org/apache/solr/common/util/StrUtils.java:
##
@@ -363,4 +366,16 @@ public static String formatString(String pattern,
Object... args) {
public static boolean isNullOrEmpty(String string) {
return string == null || string.isEmpty();
}
+
+ public static String stringFromReader(Reader inReader) throws IOException {
+try (Reader reader = new BufferedReader(inReader)) {
+ char[] arr = new char[8 * 1024];
+ StringBuilder buffer = new StringBuilder();
Review Comment:
triple buffering?!
##
solr/core/src/java/org/apache/solr/cluster/placement/plugins/MinimizeCoresPlacementFactory.java:
##
@@ -123,20 +123,23 @@ public List computePlacements(
// replicas on nodes with less cores first. We only need
totalReplicasPerShard nodes given
// that's the number of replicas to place. We assign based on the
passed
// nodeEntriesToAssign list so the right nodes get replicas.
- ArrayList> nodeEntriesToAssign =
+ List> nodeEntriesToAssign =
new ArrayList<>(totalReplicasPerShard);
- Iterator> treeIterator =
nodesByCores.entries().iterator();
+ Iterator> treeIterator =
+ nodesByCores.entrySet().stream()
+ .flatMap(e -> e.getValue().stream().map(n ->
Map.entry(e.getKey(), n)))
+ .iterator();
for (int i = 0; i < totalReplicasPerShard; i++) {
Review Comment:
Since you are adding the use of streams above, you might as well remove the
need for an iterator and for loop as well. use
`Stream.limit(totalReplicasPerShard).collect(Collectors.toList())` and then the
whole concoction becomes rather satisfying IMO.
##
solr/solrj/src/java/org/apache/solr/common/util/StrUtils.java:
##
@@ -363,4 +366,16 @@ public static String formatString(String pattern,
Object... args) {
public static boolean isNullOrEmpty(String string) {
return string == null || string.isEmpty();
}
+
+ public static String stringFromReader(Reader inReader) throws IOException {
+try (Reader reader = new BufferedReader(inReader)) {
+ char[] arr = new char[8 * 1024];
+ StringBuilder buffer = new StringBuilder();
Review Comment:
instead I recommend inReader.transferTo(StringWriter)
--
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 opened a new pull request, #1524: Update org.springframework.boot:spring-boot* to v2.7.10
solrbot opened a new pull request, #1524: URL: https://github.com/apache/solr/pull/1524 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [org.springframework.boot:spring-boot-starter-web](https://spring.io/projects/spring-boot) ([source](https://togithub.com/spring-projects/spring-boot)) | test | minor | `2.5.14` -> `2.7.10` | | [org.springframework.boot:spring-boot-starter-logging](https://spring.io/projects/spring-boot) ([source](https://togithub.com/spring-projects/spring-boot)) | test | minor | `2.5.14` -> `2.7.10` | | [org.springframework.boot:spring-boot-starter-json](https://spring.io/projects/spring-boot) ([source](https://togithub.com/spring-projects/spring-boot)) | test | minor | `2.5.14` -> `2.7.10` | | [org.springframework.boot:spring-boot-starter-jetty](https://spring.io/projects/spring-boot) ([source](https://togithub.com/spring-projects/spring-boot)) | test | minor | `2.5.14` -> `2.7.10` | | [org.springframework.boot:spring-boot-starter-actuator](https://spring.io/projects/spring-boot) ([source](https://togithub.com/spring-projects/spring-boot)) | test | minor | `2.5.14` -> `2.7.10` | | [org.springframework.boot:spring-boot-starter](https://spring.io/projects/spring-boot) ([source](https://togithub.com/spring-projects/spring-boot)) | test | minor | `2.5.14` -> `2.7.10` | | [org.springframework.boot:spring-boot-autoconfigure](https://spring.io/projects/spring-boot) ([source](https://togithub.com/spring-projects/spring-boot)) | test | minor | `2.5.14` -> `2.7.10` | | [org.springframework.boot:spring-boot-actuator-autoconfigure](https://spring.io/projects/spring-boot) ([source](https://togithub.com/spring-projects/spring-boot)) | test | minor | `2.5.14` -> `2.7.10` | | [org.springframework.boot:spring-boot-actuator](https://spring.io/projects/spring-boot) ([source](https://togithub.com/spring-projects/spring-boot)) | test | minor | `2.5.14` -> `2.7.10` | | [org.springframework.boot:spring-boot](https://spring.io/projects/spring-boot) ([source](https://togithub.com/spring-projects/spring-boot)) | test | minor | `2.5.14` -> `2.7.10` | --- ### Release Notes spring-projects/spring-boot ### [`v2.7.10`](https://togithub.com/spring-projects/spring-boot/releases/tag/v2.7.10) # :lady_beetle: Bug Fixes - Some of the deprecated spring.security.saml2.relyingparty.registration.\*.identityprovider.\* properties are ignored [#34525](https://togithub.com/spring-projects/spring-boot/issues/34525) - Maven plugin uses timezone-local timestamps when outputTimestamp is used [#34424](https://togithub.com/spring-projects/spring-boot/issues/34424) - Loading application.yml fails with NoSuchMethodError when using SnakeYAML 2.0 [#34405](https://togithub.com/spring-projects/spring-boot/issues/34405) - EmbeddedWebServerFactoryCustomizerAutoConfiguration should not run when embedded web server is not configured [#34332](https://togithub.com/spring-projects/spring-boot/pull/34332) - Image builds with podman fail when image buildpacks are configured [#34324](https://togithub.com/spring-projects/spring-boot/issues/34324) - org.springframework.boot.web.embedded.jetty.GracefulShutdown uses the wrong class to create its logger [#34220](https://togithub.com/spring-projects/spring-boot/pull/34220) - StandardConfigDataResource can import the same file twice if the classpath includes '.' [#34212](https://togithub.com/spring-projects/spring-boot/issues/34212) # :notebook_with_decorative_cover: Documentation - Document support for Java 20 [#34642](https://togithub.com/spring-projects/spring-boot/issues/34642) - Update two references to old APIs [#34567](https://togithub.com/spring-projects/spring-boot/pull/34567) - Clarify conventions for custom error pages in WebFlux [#34534](https://togithub.com/spring-projects/spring-boot/pull/34534) - Add documentation tip showing how to configure publishRegistry Maven properties from the command line [#34517](https://togithub.com/spring-projects/spring-boot/pull/34517) - Document support for Gradle 8 [#34458](https://togithub.com/spring-projects/spring-boot/issues/34458) - Document how to get socket location for image building configuration with podman [#34435](https://togithub.com/spring-projects/spring-boot/issues/34435) - Fix typo in Encrypting Properties [#34386](https://togithub.com/spring-projects/spring-boot/pull/34386) - Use plugins DSL consistently in Spring Boot Gradle Plugin docs [#34048](https://togithub.com/spring-projects/spring-boot/issues/34048) - Add link to Failover starter [#32943](https://togithub.com/spring-projects/spring-boot/pull/32943) # :hammer: Dependency Upgrades - Upgrade to Dropwizard Metrics 4.2.18 [#34648](https://togithub.com/spring-project
[GitHub] [solr] solrbot opened a new pull request, #1523: Update org.apache.kerby:* to v1.1.1
solrbot opened a new pull request, #1523: URL: https://github.com/apache/solr/pull/1523 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [org.apache.kerby:kerb-simplekdc](https://directory.apache.org/kerby) ([source](https://togithub.com/apache/directory-kerby)) | test | minor | `1.0.1` -> `1.1.1` | | [org.apache.kerby:kerb-server](https://directory.apache.org/kerby) ([source](https://togithub.com/apache/directory-kerby)) | test | minor | `1.0.1` -> `1.1.1` | | [org.apache.kerby:kerb-identity](https://directory.apache.org/kerby) ([source](https://togithub.com/apache/directory-kerby)) | test | minor | `1.0.1` -> `1.1.1` | | [org.apache.kerby:kerb-common](https://directory.apache.org/kerby) ([source](https://togithub.com/apache/directory-kerby)) | test | minor | `1.0.1` -> `1.1.1` | | [org.apache.kerby:kerb-client](https://directory.apache.org/kerby) ([source](https://togithub.com/apache/directory-kerby)) | test | minor | `1.0.1` -> `1.1.1` | | [org.apache.kerby:kerb-admin](https://directory.apache.org/kerby) ([source](https://togithub.com/apache/directory-kerby)) | test | minor | `1.0.1` -> `1.1.1` | | [org.apache.kerby:kerby-util](https://directory.apache.org/kerby) ([source](https://togithub.com/apache/directory-kerby)) | dependencies | minor | `1.0.1` -> `1.1.1` | | [org.apache.kerby:kerby-pkix](https://directory.apache.org/kerby) ([source](https://togithub.com/apache/directory-kerby)) | dependencies | minor | `1.0.1` -> `1.1.1` | | [org.apache.kerby:kerby-config](https://directory.apache.org/kerby) ([source](https://togithub.com/apache/directory-kerby)) | dependencies | minor | `1.0.1` -> `1.1.1` | | [org.apache.kerby:kerby-asn1](https://directory.apache.org/kerby) ([source](https://togithub.com/apache/directory-kerby)) | dependencies | minor | `1.0.1` -> `1.1.1` | | [org.apache.kerby:kerb-util](https://directory.apache.org/kerby) ([source](https://togithub.com/apache/directory-kerby)) | dependencies | minor | `1.0.1` -> `1.1.1` | | [org.apache.kerby:kerb-crypto](https://directory.apache.org/kerby) ([source](https://togithub.com/apache/directory-kerby)) | dependencies | minor | `1.0.1` -> `1.1.1` | | [org.apache.kerby:kerb-core](https://directory.apache.org/kerby) ([source](https://togithub.com/apache/directory-kerby)) | dependencies | minor | `1.0.1` -> `1.1.1` | --- ### Configuration 📅 **Schedule**: Branch creation - "before 3am on the first day of the month" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://togithub.com/solrbot/renovate-github-action) -- 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 opened a new pull request, #1522: Update dependency org.mockito:mockito-core to v3.12.4
solrbot opened a new pull request, #1522: URL: https://github.com/apache/solr/pull/1522 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [org.mockito:mockito-core](https://togithub.com/mockito/mockito) | test | minor | `3.8.0` -> `3.12.4` | --- ### Release Notes mockito/mockito ### [`v3.12.4`](https://togithub.com/mockito/mockito/releases/tag/v3.12.4) *Changelog generated by [Shipkit Changelog Gradle Plugin](https://togithub.com/shipkit/shipkit-changelog)* # 3.12.4 - 2021-08-25 - [1 commit(s)](https://togithub.com/mockito/mockito/compare/v3.12.3...v3.12.4) by Rafael Winterhalter - No notable improvements. No pull requests (issues) were referenced from commits. ### [`v3.12.3`](https://togithub.com/mockito/mockito/releases/tag/v3.12.3) *Changelog generated by [Shipkit Changelog Gradle Plugin](https://togithub.com/shipkit/shipkit-changelog)* # 3.12.3 - 2021-08-24 - [9 commit(s)](https://togithub.com/mockito/mockito/compare/v3.12.2...v3.12.3) by Rafael Winterhalter - Fix implementation of proxy mock maker for toString and add additional unit tests. [(#2405)](https://togithub.com/mockito/mockito/pull/2405) - Avoid cache breakage [(#2402)](https://togithub.com/mockito/mockito/pull/2402) - Add a limited mock maker that is based only on the java.lang.reflect.Proxy utility [(#2397)](https://togithub.com/mockito/mockito/pull/2397) ### [`v3.12.2`](https://togithub.com/mockito/mockito/releases/tag/v3.12.2) *Changelog generated by [Shipkit Changelog Gradle Plugin](https://togithub.com/shipkit/shipkit-changelog)* # 3.12.2 - 2021-08-24 - [2 commit(s)](https://togithub.com/mockito/mockito/compare/v3.12.1...v3.12.2) by Dmitry Vyazelenko, dependabot\[bot] - Fixes [#2399](https://togithub.com/mockito/mockito/issues/2399) : Adds defaultAnswer to the MockitoMockKey to distinguish the mock types, i.e. to separate mocks from spies otherwise spy type is reused for a mock or vice versa. [(#2400)](https://togithub.com/mockito/mockito/pull/2400) - Sporadic mock verification failures related to hashCode/equals on 3.12.1 [(#2399)](https://togithub.com/mockito/mockito/issues/2399) - Bump versions.errorprone from 2.8.1 to 2.9.0 [(#2396)](https://togithub.com/mockito/mockito/pull/2396) ### [`v3.12.1`](https://togithub.com/mockito/mockito/releases/tag/v3.12.1) *Changelog generated by [Shipkit Changelog Gradle Plugin](https://togithub.com/shipkit/shipkit-changelog)* # 3.12.1 - 2021-08-20 - [2 commit(s)](https://togithub.com/mockito/mockito/compare/v3.12.0...v3.12.1) by Tim van der Lippe, dependabot\[bot] - Fix verifyNoMoreInteractions inOrder invocations for spies [(#2395)](https://togithub.com/mockito/mockito/pull/2395) - Regression with InOrder verification after [#2369](https://togithub.com/mockito/mockito/issues/2369) [(#2394)](https://togithub.com/mockito/mockito/issues/2394) - Bump versions.bytebuddy from 1.11.12 to 1.11.13 [(#2393)](https://togithub.com/mockito/mockito/pull/2393) ### [`v3.12.0`](https://togithub.com/mockito/mockito/releases/tag/v3.12.0) *Changelog generated by [Shipkit Changelog Gradle Plugin](https://togithub.com/shipkit/shipkit-changelog)* # 3.12.0 - 2021-08-19 - [31 commit(s)](https://togithub.com/mockito/mockito/compare/v3.11.2...v3.12.0) by EugeneLesnov, Lars Vogel, Logan Rosen, Rafael Winterhalter, Rob Pridham, Tim van der Lippe, dependabot\[bot], saurabh7248 - Add checks for sealed types [(#2392)](https://togithub.com/mockito/mockito/pull/2392) - Bump versions.bytebuddy from 1.11.10 to 1.11.12 [(#2388)](https://togithub.com/mockito/mockito/pull/2388) - Bump versions.bytebuddy from 1.11.9 to 1.11.10 [(#2387)](https://togithub.com/mockito/mockito/pull/2387) - Bump versions.errorprone from 2.8.0 to 2.8.1 [(#2386)](https://togithub.com/mockito/mockito/pull/2386) - Update StaticMockTest to use unified verify method [(#2385)](https://togithub.com/mockito/mockito/pull/2385) - Reorder InjectMock Javadoc to fit the order of injection [(#2383)](https://togithub.com/mockito/mockito/pull/2383) - Bump core-ktx from 1.5.0 to 1.6.0 [(#2382)](https://togithub.com/mockito/mockito/pull/2382) - Bump google-java-format from 1.10.0 to 1.11.0 [(#2381)](https://togithub.com/mockito/mockito/pull/2381) - Downgrade Android gradle plugin [(#2380)](https://togithub.com/mockito/mockito/pull/2380) - Applied [@CheckReturnValue](https://togithub.com/CheckReturnValue) to some classes [(#2379)](https://togithub.com/mockito/mockito/pull/2379) - how to solve gradle sync failed after 'Add basic Android instrumented and unit tests' [(#2378)](https://togithub.com/mockito/mockito/issues/2378) - Bump junit from 1.1.2 t
[GitHub] [solr] solrbot opened a new pull request, #1521: Update dependency org.hsqldb:hsqldb to v2.7.1
solrbot opened a new pull request, #1521: URL: https://github.com/apache/solr/pull/1521 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [org.hsqldb:hsqldb](http://hsqldb.org) ([source](http://sourceforge.net/p/hsqldb/svn/HEAD)) | test | minor | `2.4.0` -> `2.7.1` | --- ### Configuration 📅 **Schedule**: Branch creation - "before 3am on the first day of the month" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://togithub.com/solrbot/renovate-github-action) -- 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 opened a new pull request, #1520: Update dependency no.nav.security:mock-oauth2-server to v0.5.8
solrbot opened a new pull request, #1520:
URL: https://github.com/apache/solr/pull/1520
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[no.nav.security:mock-oauth2-server](https://togithub.com/navikt/mock-oauth2-server)
| test | minor | `0.4.3` -> `0.5.8` |
---
### Release Notes
navikt/mock-oauth2-server
###
[`v0.5.8`](https://togithub.com/navikt/mock-oauth2-server/releases/tag/0.5.8)
[Compare
Source](https://togithub.com/navikt/mock-oauth2-server/compare/0.5.7...0.5.8)
What's Changed
- refactor(oauth2httprequest): simplify logic for proxy aware url
([#393](https://togithub.com/navikt/mock-oauth2-server/issues/393))
[@tommytroen](https://togithub.com/tommytroen)
🐛 Bug Fixes
- fix(ssl): support SSL/TLS from debugger client
([#407](https://togithub.com/navikt/mock-oauth2-server/issues/407))
[@tommytroen](https://togithub.com/tommytroen)
⬆️ Dependency upgrades
- chore(deps): bump io.github.gradle-nexus.publish-plugin from 1.1.0 to
1.2.0
([#434](https://togithub.com/navikt/mock-oauth2-server/issues/434))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump com.github.ben-manes.versions from 0.45.0 to 0.46.0
([#433](https://togithub.com/navikt/mock-oauth2-server/issues/433))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump com.nimbusds:oauth2-oidc-sdk from 10.5.2 to 10.7
([#432](https://togithub.com/navikt/mock-oauth2-server/issues/432))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump io.netty:netty-all from 4.1.87.Final to 4.1.89.Final
([#428](https://togithub.com/navikt/mock-oauth2-server/issues/428))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump com.nimbusds:oauth2-oidc-sdk from 10.5.1 to 10.5.2
([#429](https://togithub.com/navikt/mock-oauth2-server/issues/429))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump org.jetbrains.kotlin:kotlin-test-junit5 from 1.8.0 to
1.8.10
([#425](https://togithub.com/navikt/mock-oauth2-server/issues/425))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump ktorVersion from 2.2.2 to 2.2.3
([#421](https://togithub.com/navikt/mock-oauth2-server/issues/421))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump io.github.microutils:kotlin-logging from 3.0.4 to
3.0.5
([#422](https://togithub.com/navikt/mock-oauth2-server/issues/422))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump kotestVersion from 5.5.4 to 5.5.5
([#426](https://togithub.com/navikt/mock-oauth2-server/issues/426))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump com.github.ben-manes.versions from 0.44.0 to 0.45.0
([#423](https://togithub.com/navikt/mock-oauth2-server/issues/423))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump jvm from 1.8.0 to 1.8.10
([#424](https://togithub.com/navikt/mock-oauth2-server/issues/424))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump jacksonVersion from 2.14.1 to 2.14.2
([#420](https://togithub.com/navikt/mock-oauth2-server/issues/420))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump dependabot/fetch-metadata from 1.3.5 to 1.3.6
([#419](https://togithub.com/navikt/mock-oauth2-server/issues/419))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump assertj-core from 3.23.1 to 3.24.2
([#415](https://togithub.com/navikt/mock-oauth2-server/issues/415))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump freemarker from 2.3.31 to 2.3.32
([#414](https://togithub.com/navikt/mock-oauth2-server/issues/414))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump netty-all from 4.1.86.Final to 4.1.87.Final
([#412](https://togithub.com/navikt/mock-oauth2-server/issues/412))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump oauth2-oidc-sdk from 10.4 to 10.5.1
([#418](https://togithub.com/navikt/mock-oauth2-server/issues/418))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump junitJupiterVersion from 5.9.1 to 5.9.2
([#410](https://togithub.com/navikt/mock-oauth2-server/issues/410))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump ktorVersion from 2.2.1 to 2.2.2
([#406](https://togithub.com/navikt/mock-oauth2-server/issues/406))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump jvm from 1.7.22 to 1.8.0
([#402](https://togithub.com/navikt/mock-oauth2-server/issues/402))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump kotlin-test-junit5 from 1.7.22 to 1.8.0
([#401](https://togithub.com/navikt/mock-oauth2-server/issues/401))
[@dependabot](https://togithub.com/dependabot)
- chore(deps): bump org.jmai
[GitHub] [solr] solrbot opened a new pull request, #1519: Update dependency net.bytebuddy:byte-buddy to v1.14.2
solrbot opened a new pull request, #1519: URL: https://github.com/apache/solr/pull/1519 This PR contains the following updates: | Package | Type | Update | Change | Pending | |---|---|---|---|---| | [net.bytebuddy:byte-buddy](https://bytebuddy.net) | test | minor | `1.9.3` -> `1.14.2` | `1.14.3` | --- ### Configuration 📅 **Schedule**: Branch creation - "before 3am on the first day of the month" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://togithub.com/solrbot/renovate-github-action) -- 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 opened a new pull request, #1518: Update dependency com.google.cloud:google-cloud-bom to v0.192.0
solrbot opened a new pull request, #1518: URL: https://github.com/apache/solr/pull/1518 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [com.google.cloud:google-cloud-bom](https://togithub.com/googleapis/java-cloud-bom) | dependencies | minor | `0.190.0` -> `0.192.0` | --- ### Configuration 📅 **Schedule**: Branch creation - "before 3am on the first day of the month" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://togithub.com/solrbot/renovate-github-action) -- 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 opened a new pull request, #1517: Update dependency com.adobe.testing:s3mock-junit4 to v2.11.0
solrbot opened a new pull request, #1517: URL: https://github.com/apache/solr/pull/1517 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [com.adobe.testing:s3mock-junit4](https://togithub.com/adobe/S3Mock) | test | minor | `2.1.34` -> `2.11.0` | --- ### Release Notes adobe/S3Mock ### [`v2.11.0`](https://togithub.com/adobe/S3Mock/blob/HEAD/CHANGELOG.md#2110) [Compare Source](https://togithub.com/adobe/S3Mock/compare/2.10.2...2.11.0) 2.x is JDK8 LTS bytecode compatible, with Docker and JUnit / direct Java integration. - Features and fixes - Support for GetBucketLocation API (fixes [#985](https://togithub.com/adobe/S3Mock/issues/985)) - Version updates - Bump aws-java-sdk-s3 from 1.12.346 to 1.12.369 - Bump aws-v2.version from 2.18.21 to 2.19.1 - Bump docker-maven-plugin from 0.40.2 to 0.40.3 - Bump maven-dependency-plugin from 3.3.0 to 3.4.0 - Bump mockito-kotlin from 4.0.0 to 4.1.0 - Bump checkstyle from 10.4 to 10.5.0 - Bump kotlin.version from 1.7.21 to 1.7.22 - Bump alpine from 3.16.3 to 3.17.0 in /docker - Bump spring-boot.version from 2.7.5 to 2.7.6 ### [`v2.10.2`](https://togithub.com/adobe/S3Mock/blob/HEAD/CHANGELOG.md#2102) [Compare Source](https://togithub.com/adobe/S3Mock/compare/2.10.1...2.10.2) 2.x is JDK8 LTS bytecode compatible, with Docker and JUnit / direct Java integration. - Features and fixes - Let S3Mock return correct errors for invalid bucket names (fixes [#935](https://togithub.com/adobe/S3Mock/issues/935)) - Previous implementation returned a Spring generated error which does not disclose what's actually wrong - If the bucket name is not valid, the bucket can't be created. If a later request still contains this invalid name, S3Mock will now return a 404 not found. ### [`v2.10.1`](https://togithub.com/adobe/S3Mock/blob/HEAD/CHANGELOG.md#2101) [Compare Source](https://togithub.com/adobe/S3Mock/compare/2.10.0...2.10.1) 2.x is JDK8 LTS bytecode compatible, with Docker and JUnit / direct Java integration. - Features and fixes - Let S3Mock use streams for MD5 verification (fixes [#939](https://togithub.com/adobe/S3Mock/issues/939)) - Previous implementation read the full stream into memory, leading to OutOfMemory errors if the file is larger than the available heap. ### [`v2.10.0`](https://togithub.com/adobe/S3Mock/blob/HEAD/CHANGELOG.md#2100) [Compare Source](https://togithub.com/adobe/S3Mock/compare/2.9.1...2.10.0) 2.x is JDK8 LTS bytecode compatible, with Docker and JUnit / direct Java integration. - Features and fixes - Let S3Mock use container memory and cpu (fixes [#922](https://togithub.com/adobe/S3Mock/issues/922)) - Set resource limits through docker like this: `docker run -it --memory="1g" --cpus="1.0"` - Version updates - Bump alpine from 3.16.2 to 3.16.3 in /docker - Bump testcontainers.version from 1.17.5 to 1.17.6 - Bump maven-install-plugin from 3.0.1 to 3.1.0 - Bump aws-v2.version from 2.18.15 to 2.18.21 - Bump aws-java-sdk-s3 from 1.12.340 to 1.12.346 ### [`v2.9.1`](https://togithub.com/adobe/S3Mock/blob/HEAD/CHANGELOG.md#291) [Compare Source](https://togithub.com/adobe/S3Mock/compare/2.9.0...2.9.1) 2.x is JDK8 LTS bytecode compatible, with Docker and JUnit / direct Java integration. - Features and fixes - IDs in stores must be different for all objects (fixes [#877](https://togithub.com/adobe/S3Mock/issues/877)) ### [`v2.9.0`](https://togithub.com/adobe/S3Mock/blob/HEAD/CHANGELOG.md#290) [Compare Source](https://togithub.com/adobe/S3Mock/compare/2.8.0...2.9.0) 2.x is JDK8 LTS bytecode compatible, with Docker and JUnit / direct Java integration. - Features and fixes - Support restarting S3Mock with the `retainFilesOnExit` option enabled. (fixes [#818](https://togithub.com/adobe/S3Mock/issues/818), [#877](https://togithub.com/adobe/S3Mock/issues/877)) - Let AWS SDKv2 use path style access (fixes [#880](https://togithub.com/adobe/S3Mock/issues/880)) - Starting with AWS SDKv2.18.x domain style access is the default. This is currently not supported by S3Mock. - Version updates - Bump aws-v2.version from 2.17.284 to 2.18.15 - Bump aws-java-sdk-s3 from 1.12.313 to 1.12.340 - Bump kotlin.version from 1.7.20 to 1.7.21 - Bump maven-release-plugin from 3.0.0-M6 to 3.0.0-M7 - Bump checkstyle from 10.3.4 to 10.4 - Bump spring-boot.version from 2.7.4 to 2.7.5 - Bump testcontainers.version from 1.17.4 to 1.17.5 ### [`v2.8.0`](https
[GitHub] [solr] solrbot opened a new pull request, #1516: Update org.springframework:spring* to v5.3.26
solrbot opened a new pull request, #1516: URL: https://github.com/apache/solr/pull/1516 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [org.springframework:spring-webmvc](https://togithub.com/spring-projects/spring-framework) | test | patch | `5.3.23` -> `5.3.26` | | [org.springframework:spring-web](https://togithub.com/spring-projects/spring-framework) | test | patch | `5.3.23` -> `5.3.26` | | [org.springframework:spring-jcl](https://togithub.com/spring-projects/spring-framework) | test | patch | `5.3.23` -> `5.3.26` | | [org.springframework:spring-expression](https://togithub.com/spring-projects/spring-framework) | test | patch | `5.3.23` -> `5.3.26` | | [org.springframework:spring-core](https://togithub.com/spring-projects/spring-framework) | test | patch | `5.3.23` -> `5.3.26` | | [org.springframework:spring-context](https://togithub.com/spring-projects/spring-framework) | test | patch | `5.3.23` -> `5.3.26` | | [org.springframework:spring-beans](https://togithub.com/spring-projects/spring-framework) | test | patch | `5.3.23` -> `5.3.26` | | [org.springframework:spring-aop](https://togithub.com/spring-projects/spring-framework) | test | patch | `5.3.23` -> `5.3.26` | --- ### Release Notes spring-projects/spring-framework ### [`v5.3.26`](https://togithub.com/spring-projects/spring-framework/releases/tag/v5.3.26) # :star: New Features - Improve diagnostics in SpEL for `matches` operator [#30145](https://togithub.com/spring-projects/spring-framework/issues/30145) - Improve diagnostics in SpEL for repeated text [#30143](https://togithub.com/spring-projects/spring-framework/issues/30143) - Increase scope of regex pattern cache for the SpEL `matches` operator [#30141](https://togithub.com/spring-projects/spring-framework/issues/30141) - Minor updates in HandlerMappingIntrospector [#30128](https://togithub.com/spring-projects/spring-framework/issues/30128) - Allow SnakeYaml 2.0 runtime compatibility [#30097](https://togithub.com/spring-projects/spring-framework/issues/30097) - Add missing `@Nullable` annotations to `LogMessage.format` methods [#30009](https://togithub.com/spring-projects/spring-framework/issues/30009) - ASM upgrade for JDK 20/21 support [#29966](https://togithub.com/spring-projects/spring-framework/issues/29966) - Allow MockRest to match header/queryParam value list with one Matcher [#29964](https://togithub.com/spring-projects/spring-framework/issues/29964) - Add `MockMvc.multipart()` Kotlin extensions with `HttpMethod` [#29941](https://togithub.com/spring-projects/spring-framework/issues/29941) - Release R2DBC connection when cleanup fails in transaction [#29925](https://togithub.com/spring-projects/spring-framework/issues/29925) - org.springframework.web.context.ContextLoader should lazily load ContextLoader.properties [#29909](https://togithub.com/spring-projects/spring-framework/issues/29909) - Improve generated default name for `@JmsListener` subscription [#29902](https://togithub.com/spring-projects/spring-framework/issues/29902) - Include all Hibernate query methods in `SharedEntityManagerCreator`'s `queryTerminatingMethods` set [#29888](https://togithub.com/spring-projects/spring-framework/issues/29888) - SQL supplier in R2DBC `DatabaseClient` is eagerly invoked [#29887](https://togithub.com/spring-projects/spring-framework/issues/29887) - Spring Framework 5.3.x is incompatible with Jetty 10 (Client) [#29867](https://togithub.com/spring-projects/spring-framework/issues/29867) - Possible infinite forward loop with MockMvcWebConnection [#29866](https://togithub.com/spring-projects/spring-framework/issues/29866) - Refine `Jackson2ObjectMapperBuilder#configureFeature` exception handling [#29860](https://togithub.com/spring-projects/spring-framework/issues/29860) - Fix R2dbcTransactionManager debug log: don't log a Mono [#29824](https://togithub.com/spring-projects/spring-framework/issues/29824) # :lady_beetle: Bug Fixes - RequestedContentTypeResolver does not ignore quality factor when filtering \*/\* media types [#30121](https://togithub.com/spring-projects/spring-framework/issues/30121) - SpEL: cannot call methods declared in `java.lang.Object` on a JDK proxy [#30118](https://togithub.com/spring-projects/spring-framework/issues/30118) - CaffeineCacheManager getCache method cause thread block [#30085](https://togithub.com/spring-projects/spring-framework/issues/30085) - Protect JMS connection creation against prepareConnection errors [#30051](https://togithub.com/spring-projects/spring-framework/issues/30051) - ReactorServerHttpRequest does not reflect forwarded host and port when `forwarding-header-strategy=native` or cloud platform detected [#29974](https:/
[GitHub] [solr] solrbot opened a new pull request, #1515: Update org.apache.hadoop:* to v3.3.5
solrbot opened a new pull request, #1515: URL: https://github.com/apache/solr/pull/1515 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | org.apache.hadoop:hadoop-minikdc | test | patch | `3.3.4` -> `3.3.5` | | org.apache.hadoop:hadoop-hdfs | test | patch | `3.3.4` -> `3.3.5` | | org.apache.hadoop:hadoop-client-minicluster | test | patch | `3.3.4` -> `3.3.5` | | org.apache.hadoop:hadoop-common | dependencies | patch | `3.3.4` -> `3.3.5` | | org.apache.hadoop:hadoop-client-runtime | dependencies | patch | `3.3.4` -> `3.3.5` | | org.apache.hadoop:hadoop-client-api | dependencies | patch | `3.3.4` -> `3.3.5` | | org.apache.hadoop:hadoop-auth | dependencies | patch | `3.3.4` -> `3.3.5` | | org.apache.hadoop:hadoop-annotations | dependencies | patch | `3.3.4` -> `3.3.5` | --- ### Configuration 📅 **Schedule**: Branch creation - "before 3am on the first day of the month" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://togithub.com/solrbot/renovate-github-action) -- 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-16220) Documentation leads to NPE Missing SslContextFactory for SolrJ client
[
https://issues.apache.org/jira/browse/SOLR-16220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707465#comment-17707465
]
Jan Høydahl commented on SOLR-16220:
Is this related to SOLR-16668? Perhaps it works in 9.2?
> Documentation leads to NPE Missing SslContextFactory for SolrJ client
> -
>
> Key: SOLR-16220
> URL: https://issues.apache.org/jira/browse/SOLR-16220
> Project: Solr
> Issue Type: Bug
> Components: documentation, SolrJ
>Affects Versions: 9.0
> Environment: JDK used is:
> {noformat}
> openjdk 11.0.14.1 2022-02-08 LTS
> OpenJDK Runtime Environment Zulu11.54+26-SA (build 11.0.14.1+1-LTS)
> OpenJDK 64-Bit Server VM Zulu11.54+26-SA (build 11.0.14.1+1-LTS, mixed
> mode){noformat}
>Reporter: Gunnar Wagenknecht
>Priority: Minor
> Labels: newdev
>
> Following the documentation here:
> [https://solr.apache.org/guide/solr/latest/deployment-guide/solrj.html]
>
> This code leads to an NPE:
> {noformat}
> Http2SolrClient mavenCentralRepo = new
> Http2SolrClient.Builder("https://search.maven.org/solrsearch";).build();
> final SolrQuery query = new SolrQuery("fc:" + className);
> query.setRows(20);
> QueryResponse response = mavenCentralRepo.query(query);{noformat}
> NPE:
> {noformat}
> java.lang.NullPointerException: Missing SslContextFactory
> at java.base/java.util.Objects.requireNonNull(Objects.java:246)
> at
> org.eclipse.jetty.io.ssl.SslClientConnectionFactory.(SslClientConnectionFactory.java:57)
> at
> org.eclipse.jetty.client.HttpClient.newSslClientConnectionFactory(HttpClient.java:1208)
> at
> org.eclipse.jetty.client.HttpClient.newSslClientConnectionFactory(HttpClient.java:1214)
> at
> org.eclipse.jetty.client.HttpDestination.newSslClientConnectionFactory(HttpDestination.java:148)
> at
> org.eclipse.jetty.client.HttpDestination.newSslClientConnectionFactory(HttpDestination.java:154)
> at
> org.eclipse.jetty.client.HttpDestination.(HttpDestination.java:94)
> at
> org.eclipse.jetty.client.MultiplexHttpDestination.(MultiplexHttpDestination.java:25)
> at
> org.eclipse.jetty.http2.client.http.HttpDestinationOverHTTP2.(HttpDestinationOverHTTP2.java:32)
> at
> org.eclipse.jetty.http2.client.http.HttpClientTransportOverHTTP2.newHttpDestination(HttpClientTransportOverHTTP2.java:128)
> at
> org.eclipse.jetty.client.HttpClient.lambda$resolveDestination$0(HttpClient.java:575)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1705)
> at
> org.eclipse.jetty.client.HttpClient.resolveDestination(HttpClient.java:573)
> at
> org.eclipse.jetty.client.HttpClient.resolveDestination(HttpClient.java:551)
> at org.eclipse.jetty.client.HttpClient.send(HttpClient.java:599)
> at org.eclipse.jetty.client.HttpRequest.sendAsync(HttpRequest.java:778)
> at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:765)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:448)
> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:217)
> at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:927)
> at
> org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:940){noformat}
> I think there is a bug in Http2SolrClient somewhere. Such URLs should be
> supported out of the box on a Java 11 JDK without requiring users to provide
> system properties or other custom initialization. Otherwise it should be
> documented but I couldn't find anything related to TLS/SSL configuration in
> the doc mentioned above.
--
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-15948) Server can't be stopped if there are startup errors
[
https://issues.apache.org/jira/browse/SOLR-15948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707464#comment-17707464
]
Jan Høydahl commented on SOLR-15948:
Any update on this? How do you provoke the startup error?
> Server can't be stopped if there are startup errors
> ---
>
> Key: SOLR-15948
> URL: https://issues.apache.org/jira/browse/SOLR-15948
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.0
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>
> If there are startup errors during
> {code}
> bin/solr -c
> {code}
> then a subsequent
> {code}
> bin/solr stop
> {code}
> doesn't work and times out.
--
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-16557) Solr 9.0.0 - Not able to install 3rd party DIH plugin
[ https://issues.apache.org/jira/browse/SOLR-16557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-16557. Assignee: (was: Ishan Chattopadhyaya) Resolution: Cannot Reproduce Closing as cannot reproduce. I tested locally and I could install the repo. However could not install the package on Solr 9.x as the package explicitly says in its manifest that it is for solr 8.x only. The NPE you are experiencing is due to a bad or missing Zookeeper connection string (ZK_HOST). We'd need more detailed instructions on how you ended up there to reproduce it. WRT Data Import Handler, please contact that project to request support for newer versions of Solr, but don't have your hopes too high, 2 yrs since last activity... > Solr 9.0.0 - Not able to install 3rd party DIH plugin > - > > Key: SOLR-16557 > URL: https://issues.apache.org/jira/browse/SOLR-16557 > Project: Solr > Issue Type: Bug >Affects Versions: 9.0 >Reporter: Rajesh Kumar C >Priority: Critical > > Hi Team, > > I have checked in IRC Channel & sent mail to User mailing list, as well. As > there is no update, creating a ticket here. > > We were using the Solr 8.11.1 stand alone version for quite some time. To > upgrade, I have just installed Java 11 & Solr 9.0.0. As I know DIH removed > from Solr 9, I tried to install > "[https://github.com/rohitbemax/dataimporthandler]"; 3rd party plugin > suggested by Solr. It has support to install it through Package manager, but > Package manager is not working in Solr Stand alone mode, getting below error > when executing command provided in above 3rd party plugin. > /opt/solr-9.0.0/bin/solr package add-repo data-import-handler > "https://raw.githubusercontent.com/rohitbemax/dataimporthandler/master/repo/"; > Found 1 Solr nodes: > Solr process 31961 running on port 8983 > org.apache.solr.common.SolrException: java.lang.NullPointerException > at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:240) > at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:135) > at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:126) > at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:96) > at > org.apache.solr.packagemanager.PackageManager.(PackageManager.java:82) > at org.apache.solr.util.PackageTool.runImpl(PackageTool.java:86) > at org.apache.solr.util.SolrCLI$ToolBase.runTool(SolrCLI.java:169) > at org.apache.solr.util.SolrCLI.main(SolrCLI.java:284) > Caused by: java.lang.NullPointerException > at > org.apache.zookeeper.client.ConnectStringParser.(ConnectStringParser.java:54) > at > org.apache.zookeeper.ZooKeeper.createDefaultHostProvider(ZooKeeper.java:1135) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:734) > at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:448) > at > org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:43) > at > org.apache.solr.common.cloud.ZkClientConnectionStrategy.createSolrZooKeeper(ZkClientConnectionStrategy.java:115) > at > org.apache.solr.common.cloud.DefaultConnectionStrategy.connect(DefaultConnectionStrategy.java:35) > at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:215) > ... 7 more > ERROR: java.lang.NullPointerException > > Also I have noticed that the above plugin has DIH JAR file upto Solr 8.10 > version, and does not have a DIH JAR file for Solr 9.0.0 version. > > So these are my questions. > > 1. How to install the above 3rd party DIH plugin in Solr 9.0.0 in "Stand > alone mode"? > 2. Does the above 3rd party plugin support Solr 9.0.0 version. If not, what > is the workaround to use DIH in Solr 9.0.0? > 3. Is there any other alternative (like DIH), to import data from database to > Solr? > > Please advise on the above. Thank you. -- 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-16605) CPU in UI cloud->nodes is always 0%, even when Solr is very busy.
[ https://issues.apache.org/jira/browse/SOLR-16605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-16605. Fix Version/s: 9.2 Resolution: Fixed Since the commit was released in 9.2, I'll go ahead and resolve this. Please open another Jira if you feel there is a better way to pick up CPU load from Java. > CPU in UI cloud->nodes is always 0%, even when Solr is very busy. > - > > Key: SOLR-16605 > URL: https://issues.apache.org/jira/browse/SOLR-16605 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 9.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Major > Fix For: 9.2 > > Attachments: fixcpuadminui-1.patch > > > The Cloud->Nodes section of the admin UI is always reporting 0% CPU even on > very busy Solr nodes. I thought the attached patch would fix t, but it > doesn't seem to be working. Instead of always 0%, it now shows an occasional > 50% or 100%... and even rarer is a different percentage like 84% or 17%. The > Solr process at that time was usng about 180% CPU (two CPUs in AWS instance). > Using OperatingSystemMXBean from com.sun instead of java.lang seemed to work > fine in a quick test program, but it's not working in Solr. I am trying this > on Ubuntu Linux with OpenJDK 17 and 11. -- 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-13182) NullPointerException due to an invariant violation in org/apache/lucene/search/BooleanClause.java[60]
[
https://issues.apache.org/jira/browse/SOLR-13182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707452#comment-17707452
]
Jan Høydahl commented on SOLR-13182:
What is the state of this JIRA? The PR is closed...
> NullPointerException due to an invariant violation in
> org/apache/lucene/search/BooleanClause.java[60]
> -
>
> Key: SOLR-13182
> URL: https://issues.apache.org/jira/browse/SOLR-13182
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.0
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Marek
>Priority: Minor
> Labels: diffblue, newdev
> Attachments: SOLR-13182.patch, home.zip
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?q={!child%20q={}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> ERROR (qtp689401025-14) [ x:films] o.a.s.h.RequestHandlerBase
> java.lang.NullPointerException: Query must not be null
> at java.util.Objects.requireNonNull(Objects.java:228)
> at org.apache.lucene.search.BooleanClause.(BooleanClause.java:60)
> at org.apache.lucene.search.BooleanQuery$Builder.add(BooleanQuery.java:127)
> at
> org.apache.solr.search.join.BlockJoinChildQParser.noClausesQuery(BlockJoinChildQParser.java:50)
> at org.apache.solr.search.join.FiltersQParser.parse(FiltersQParser.java:60)
> at org.apache.solr.search.QParser.getQuery(QParser.java:173)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:158)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
> [...]
> {noformat}
> In org/apache/solr/search/join/BlockJoinChildQParser.java[47] there is
> computed query variable 'parents', which receives value null from call to
> 'parseParentFilter()'. The null value is then passed to
> 'org.apache.lucene.search.BooleanQuery.Builder.add' method at line 50. That
> method calls the constructor where 'Objects.requireNonNull' failes
> (the exception is thrown).
> The call to 'parseParentFilter()' evaluates to null, because:
> # In org/apache/solr/search/join/BlockJoinParentQParser.java[59] null is
> set to string 'filter' (becase "which" is not in 'localParams' map).
> # The parser 'parentParser' obtained in the next line has member 'qstr' set
> to null, because the 'filter' passed to 'subQuery' is passed as the first
> argument to 'org.apache.solr.search.QParserPlugin.createParser'.
> # Subsequnt call to 'org.apache.solr.search.QParser.getQuery' on the
> '
[jira] [Commented] (SOLR-16659) DistribPackageStore.distribute may alter node name
[
https://issues.apache.org/jira/browse/SOLR-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707451#comment-17707451
]
Jan Høydahl commented on SOLR-16659:
[~defonion] feel free to ask if you need some guidance..
> DistribPackageStore.distribute may alter node name
> --
>
> Key: SOLR-16659
> URL: https://issues.apache.org/jira/browse/SOLR-16659
> Project: Solr
> Issue Type: Bug
> Components: Package Manager
>Affects Versions: 9.1.1
>Reporter: def onion
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
>
> This bug occurs when using the package manager in solr cloud mode with solr
> nodes that have a node name starting with "solr".
> The [distribute
> |https://github.com/apache/solr/blob/08e4591fd7f6f92c3dc42b4b1f334a960358fa4e/solr/core/src/java/org/apache/solr/filestore/DistribPackageStore.java#L365]method
> in the DistribPackageStore alters the URL of the solr nodes by replacing the
> string "/solr" with "/api". This can lead to wrong host names of solr nodes,
> e.g. "http://solr-2.solrcluster:8983"; is changed to
> "http://api-2.solrcluster:8983":
> {code:java}
> 2023-02-15 09:34:29.049 ERROR (qtp35984028-19) [] o.a.s.c.u.Utils Error in
> request to url :
> http://api-2.solrcluster:8983/api/node/files/_trusted_/keys/store-key?getFrom=solr-0.solrcluster:8983_solr
> => java.net.UnknownHostException: api-2.solrcluster
> at java.base/java.net.InetAddress$CachedAddresses.get(Unknown Source)
> {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] [Assigned] (SOLR-16649) Http2SolrClient.processErrorsAndResponse uses wrong instance of ResponseParser
[
https://issues.apache.org/jira/browse/SOLR-16649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-16649:
--
Assignee: Jan Høydahl
> Http2SolrClient.processErrorsAndResponse uses wrong instance of ResponseParser
> --
>
> Key: SOLR-16649
> URL: https://issues.apache.org/jira/browse/SOLR-16649
> Project: Solr
> Issue Type: Bug
> Components: clients - java
>Affects Versions: main (10.0), 9.1.1
>Reporter: Andrzej Bialecki
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: SOLR-16649-1.patch, SOLR-16649.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Http2SolrClient:800}} calls {{wantStream(...)}} method but passes the wrong
> argument to it - instead of passing the local {{processor}} arg it uses the
> instance field {{parser}}.
> Throughout this class there's a repeated pattern that easily leads to this
> confusion - in many methods a local var {{parser}} is created that
> overshadows the instance field, and then this local {{parser}} is passed
> around as argument to various operations. However, in this particular method
> the argument passed from the caller is named differently ({{processor}}) and
> thus does not overshadow the instance field, which leads to this mistake.
--
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, #1514: SOLR-16649 Http2SolrClient.processErrorsAndResponse uses wrong instance of ResponseParser
janhoy opened a new pull request, #1514: URL: https://github.com/apache/solr/pull/1514 https://issues.apache.org/jira/browse/SOLR-16649 Converted patch into PR, added CHANGES -- 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-16688) RELOAD in collections admin does not work on aliases
[ https://issues.apache.org/jira/browse/SOLR-16688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707449#comment-17707449 ] Jan Høydahl commented on SOLR-16688: I think you should change type to "Feature request", since we do not document that this is an intended feature. It might be useful to make aliases behave like collections in more cases. > RELOAD in collections admin does not work on aliases > > > Key: SOLR-16688 > URL: https://issues.apache.org/jira/browse/SOLR-16688 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 9.1 >Reporter: Shawn Heisey >Priority: Minor > > I have a very small cloud install – one node with the embedded zookeeper. > Today I decided that I would use a collection alias to make it easier to test > alternate configs. Got it set up fine, and then when I ran my reindex > script, which does a collection reload as part of its work, the reload failed. > I can't think of a good reason to NOT allow reloads on an alias. > -- 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-16523) Upgrade jattach in 8.11 Dockerfile after Solr 9.2 release
[ https://issues.apache.org/jira/browse/SOLR-16523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-16523. Resolution: Fixed The PR [https://github.com/docker-library/official-images/pull/14382] needs to be ack'ed and then the release will happen! > Upgrade jattach in 8.11 Dockerfile after Solr 9.2 release > - > > Key: SOLR-16523 > URL: https://issues.apache.org/jira/browse/SOLR-16523 > Project: Solr > Issue Type: Improvement > Components: Docker >Affects Versions: 8.11.2 >Reporter: Ritchie Gu >Assignee: Jan Høydahl >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > I noticed that as part of the process, it's installing gosu and few other > packages > [https://github.com/apache/solr-docker/blob/main/8.11-slim/Dockerfile#L20,] > The version of gosu gets installed is a bit of old, and do you have any plan > to install newer version gosu in? > > CVE-2022-27664 > https://nvd.nist.gov/vuln/detail/CVE-2022-27664 -- 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] janhoy merged pull request #14: SOLR-16523 Update the jattach version to 2.0
janhoy merged PR #14: URL: https://github.com/apache/solr-docker/pull/14 -- 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-docker] janhoy commented on pull request #14: SOLR-16523 Update the jattach version to 2.0
janhoy commented on PR #14: URL: https://github.com/apache/solr-docker/pull/14#issuecomment-1492715535 Think this is good now. -- 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 commented on a diff in pull request #1513: SOLR-15703: replace all SolrException.log usage in Solr to just call log.error(...) directly
risdenk commented on code in PR #1513:
URL: https://github.com/apache/solr/pull/1513#discussion_r1154885795
##
solr/core/src/java/org/apache/solr/core/SolrCore.java:
##
@@ -3013,10 +3013,6 @@ public static void postDecorateResponse(
}
}
- public static final void log(Throwable e) {
-SolrException.log(log, null, e);
- }
Review Comment:
I can leave this to cleanup w/ the other SolrException.log, but this was
only used in 3 places so just cleaned it up.
##
solr/solrj/src/java/org/apache/solr/common/SolrException.java:
##
@@ -139,6 +140,7 @@ public String getRootThrowable() {
* @deprecated Use the Logger directly
*/
@Deprecated
+ @SuppressForbidden(reason = "self referencing")
public void log(Logger log) {
Review Comment:
I'm going to remove all of these `log` methods in main once this is merged.
--
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-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=17707422#comment-17707422
]
ASF subversion and git services commented on SOLR-16721:
Commit efab25bd4c94a08b83f74bb2a55711f81100835f in solr's branch
refs/heads/branch_9x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=efab25bd4c9 ]
SOLR-16721 Java version detection fails when `_JAVA_OPTIONS` is set (#1502)
> 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
> Fix For: 9.3
>
> Time Spent: 2h
> 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] [Resolved] (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 resolved SOLR-16721.
Fix Version/s: 9.3
Resolution: Fixed
> 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
> Fix For: 9.3
>
> Time Spent: 2h
> 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=17707420#comment-17707420
]
ASF subversion and git services commented on SOLR-16721:
Commit f7fe594cdadeadd1e0061075a55a529793e72462 in solr's branch
refs/heads/main from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=f7fe594cdad ]
SOLR-16721 Java version detection fails when `_JAVA_OPTIONS` is set (#1502)
> 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: 2h
> 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] janhoy merged pull request #1502: SOLR-16721 Java version detection fails when `_JAVA_OPTIONS` is set
janhoy merged PR #1502: URL: https://github.com/apache/solr/pull/1502 -- 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 closed pull request #1254: SOLR-16599: use ventilated prose only in docs
epugh closed pull request #1254: SOLR-16599: use ventilated prose only in docs URL: https://github.com/apache/solr/pull/1254 -- 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 #1254: SOLR-16599: use ventilated prose only in docs
epugh commented on PR #1254: URL: https://github.com/apache/solr/pull/1254#issuecomment-1492592317 I am going to close this PR... It doesn't make sense to check it if we don't have a good way to convert everything over first. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] epugh commented on pull request #1107: SOLR-9775 fixed NPEs
epugh commented on PR #1107: URL: https://github.com/apache/solr/pull/1107#issuecomment-1492589453 @stillalex can you push up to this PR the changes you were thinking about? -- 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 #1107: SOLR-9775 fixed NPEs
epugh commented on PR #1107: URL: https://github.com/apache/solr/pull/1107#issuecomment-1492586901 @stillalex @risdenk I'm starting to look at various PR's that I've had open for a long time, and trying to get them merged or closed. Are we still happy with this one? -- 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 pull request #1512: SOLR-16731: Use the right cluster property for determining if TLS is enabled
janhoy commented on PR #1512: URL: https://github.com/apache/solr/pull/1512#issuecomment-1492585215 Ah, I see :) -- 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-15703) replace all SolrException.log usage in Solr to just call log.error(...) directly
[
https://issues.apache.org/jira/browse/SOLR-15703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-15703:
Status: Patch Available (was: Open)
> replace all SolrException.log usage in Solr to just call log.error(...)
> directly
>
>
> Key: SOLR-15703
> URL: https://issues.apache.org/jira/browse/SOLR-15703
> Project: Solr
> Issue Type: Sub-task
>Reporter: Chris M. Hostetter
>Assignee: Kevin Risden
>Priority: Minor
> Labels: newdev
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a lot of code in Solr that uses {{SolrException.log(log, ..)}} as a
> way to ensure that the resulting exception can be "ignored" in tests via
> {{SolrException.ignorePatterns}} / {{SolrTestCaseJ4.ignoreException()}}
> This "test feature" is being cleaned up / replaced in SOLR-15697 so that
> _any_ log message can be "muted" - meaning we don't need this special
> hook/hack – we can replace all calls to {{SolrException.log(log, ..)}} with
> (more efficient) direct calls to {{log.error(..)}}
> But this change isn't trivially to do in a scripted/automated manner –
> notably many of these {{SolrException.log(log, ..)}} use string concatenation
> that needs to be replaced with logging parameterization to pass our
> {{validateLogCalls}} check.
--
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, #1513: SOLR-15703: replace all SolrException.log usage in Solr to just call log.error(...) directly
risdenk opened a new pull request, #1513: URL: https://github.com/apache/solr/pull/1513 https://issues.apache.org/jira/browse/SOLR-15703 -- 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] beettlle opened a new pull request, #541: Update local_tutorial.md
beettlle opened a new pull request, #541: URL: https://github.com/apache/solr-operator/pull/541 Updating the version of the Autoscaler as it's deprecated. `Warning: autoscaling/v2beta2 HorizontalPodAutoscaler is deprecated in v1.23+, unavailable in v1.26+; use autoscaling/v2 HorizontalPodAutoscaler` And fixing the apiVersion as it's '.org' and not '.com' ``` % kubectl api-resources -o wide | grep SolrCloud solrcloudssolr solr.apache.org/v1beta1 true SolrCloud ``` -- 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-15703) replace all SolrException.log usage in Solr to just call log.error(...) directly
[
https://issues.apache.org/jira/browse/SOLR-15703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-15703:
Priority: Minor (was: Major)
> replace all SolrException.log usage in Solr to just call log.error(...)
> directly
>
>
> Key: SOLR-15703
> URL: https://issues.apache.org/jira/browse/SOLR-15703
> Project: Solr
> Issue Type: Sub-task
>Reporter: Chris M. Hostetter
>Assignee: Kevin Risden
>Priority: Minor
> Labels: newdev
>
> There is a lot of code in Solr that uses {{SolrException.log(log, ..)}} as a
> way to ensure that the resulting exception can be "ignored" in tests via
> {{SolrException.ignorePatterns}} / {{SolrTestCaseJ4.ignoreException()}}
> This "test feature" is being cleaned up / replaced in SOLR-15697 so that
> _any_ log message can be "muted" - meaning we don't need this special
> hook/hack – we can replace all calls to {{SolrException.log(log, ..)}} with
> (more efficient) direct calls to {{log.error(..)}}
> But this change isn't trivially to do in a scripted/automated manner –
> notably many of these {{SolrException.log(log, ..)}} use string concatenation
> that needs to be replaced with logging parameterization to pass our
> {{validateLogCalls}} check.
--
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-16507) Remove NodeStateProvider & Snitch
[ https://issues.apache.org/jira/browse/SOLR-16507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707407#comment-17707407 ] ASF subversion and git services commented on SOLR-16507: Commit e44cef4efecd412e293cb43bc186c82190ea47e0 in solr's branch refs/heads/main from Kevin Risden [ https://gitbox.apache.org/repos/asf?p=solr.git;h=e44cef4efec ] SOLR-16507: Fix CHANGES > Remove NodeStateProvider & Snitch > - > > Key: SOLR-16507 > URL: https://issues.apache.org/jira/browse/SOLR-16507 > Project: Solr > Issue Type: Task >Reporter: David Smiley >Priority: Major > Labels: newdev > Time Spent: 1.5h > Remaining Estimate: 0h > > The NodeStateProvider is a relic relating to the old autoscaling framework > that was removed in Solr 9. The only remaining usage of it is for > SplitShardCmd to check the disk space. For this, it could use the metrics > api. > I think we'll observe that Snitch and other classes in > org.apache.solr.common.cloud.rule can be removed as well, as it's related to > NodeStateProvider. > Only > org.apache.solr.cluster.placement.impl.AttributeFetcherImpl#getMetricSnitchTag > and org.apache.solr.cluster.placement.impl.NodeMetricImpl refer to some > constants in the code to be removed. Those constants could move out, > consolidated somewhere we think is appropriate. -- 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-15703) replace all SolrException.log usage in Solr to just call log.error(...) directly
[
https://issues.apache.org/jira/browse/SOLR-15703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden reassigned SOLR-15703:
---
Assignee: Kevin Risden (was: Chris M. Hostetter)
> replace all SolrException.log usage in Solr to just call log.error(...)
> directly
>
>
> Key: SOLR-15703
> URL: https://issues.apache.org/jira/browse/SOLR-15703
> Project: Solr
> Issue Type: Sub-task
>Reporter: Chris M. Hostetter
>Assignee: Kevin Risden
>Priority: Major
> Labels: newdev
>
> There is a lot of code in Solr that uses {{SolrException.log(log, ..)}} as a
> way to ensure that the resulting exception can be "ignored" in tests via
> {{SolrException.ignorePatterns}} / {{SolrTestCaseJ4.ignoreException()}}
> This "test feature" is being cleaned up / replaced in SOLR-15697 so that
> _any_ log message can be "muted" - meaning we don't need this special
> hook/hack – we can replace all calls to {{SolrException.log(log, ..)}} with
> (more efficient) direct calls to {{log.error(..)}}
> But this change isn't trivially to do in a scripted/automated manner –
> notably many of these {{SolrException.log(log, ..)}} use string concatenation
> that needs to be replaced with logging parameterization to pass our
> {{validateLogCalls}} check.
--
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] HoustonPutman opened a new pull request, #540: Add CRD options, helm options and a changelog entry
HoustonPutman opened a new pull request, #540: URL: https://github.com/apache/solr-operator/pull/540 resolves https://github.com/apache/solr-operator/issues/538 List to do: - [ ] Create CRD Options - [ ] Implement feature in controllers - [ ] Add unit tests - [ ] Add Helm values and docs - [ ] Implement Helm values in SolrCloud creation - [ ] Add docs - [ ] Add changelog -- 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] stillalex commented on pull request #1504: SOLR-7609 ShardSplitTest NPE investigation
stillalex commented on PR #1504: URL: https://github.com/apache/solr/pull/1504#issuecomment-1492480511 seeing some local failures due to the newly added 0 version check ``` org.apache.solr.search.TestRecovery > testLogReplayWithReorderedDBQByAsterixAndChildDocs FAILED java.lang.Exception: org.apache.solr.common.SolrException: missing _version_ on update from leader at __randomizedtesting.SeedInfo.seed([FE85400FD82E3172:9A3E186DD2648A17]:0) at org.apache.solr.search.TestRecovery.testLogReplayWithReorderedDBQWrapper(TestRecovery.java:616) at org.apache.solr.search.TestRecovery.testLogReplayWithReorderedDBQByAsterixAndChildDocs(TestRecovery.java:430) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1758) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:946) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:982) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:996) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:80) at org.junit.rules.RunRules.evaluate(RunRules.java:20) at org.apache.lucene.tests.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:44) at org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43) at org.apache.lucene.tests.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:45) at org.apache.lucene.tests.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:60) at org.apache.lucene.tests.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:44) at org.junit.rules.RunRules.evaluate(RunRules.java:20) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:390) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:843) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:490) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:955) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:840) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:902) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43) at org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:80) at org.junit.rules.RunRules.evaluate(RunRules.java:20) at org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.tests.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.tests.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43) at org.apache.lucene.tests.uti
[GitHub] [solr] risdenk commented on pull request #1501: SOLR-16713: Replace Guava usages with pure Java (part 2)
risdenk commented on PR #1501: URL: https://github.com/apache/solr/pull/1501#issuecomment-1492460113 > Ahh ok I get that, but why do all of the readers need to be wrapped by BufferedReader first? yea so they don't that is left over from a previous iteration where I was using BufferedReader.lines() I can fix 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
[jira] [Commented] (SOLR-7609) ShardSplitTest NPE
[
https://issues.apache.org/jira/browse/SOLR-7609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707396#comment-17707396
]
Alex Deparvu commented on SOLR-7609:
(pasting my PR comment here as well, for future reference
https://github.com/apache/solr/pull/1504#issuecomment-1492441639)
I have pushed a tentative patch for review and more importantly for discussion.
I have ran this test extensively (hundreds of beast jobs) and it looks like
this is the way to go, all 'add' exceptions are gone once the isLeader flag is
updated. BUT I am not completely convinced this is the correct patch. possibly
something could be made better in the DistributedZkUpdateProcessor area instead
(where a lot of leader calculations are being made but the result is not
correct in this edge case).
While I am still evaluating a patch for DistributedZkUpdateProcessor, I would
love some feedback on the observations so far.
More on the isLeader update: I have decided to only do this in the case where
it can be used to avoid throwing an exception. this was to add a best-effort
way correct an inconsistent state before bailing out, possibly a cleaner fix
would compute the 'isLeader' flag in a way that this approach is no longer
needed.
Together with the patch I have added a check which will not allow additions
with no version. this is now consistent with the delete flows. although I must
admit I am confused by the fact that this check was missing on this execution
path, while the delete path had this from at least 8 years ago.
Other points
* in the current test, there are a few operations (add and deletes) that run
parallel to the split operation. these can fail and this is where the bug is.
because the exceptions are not correctly accounted for, the NPE popped up at a
weird place. I added tracking and assertions on this part too (except for
deletes, see below)
* deletes can also cause exceptions, I don't have a good handle on how to fix
this, so I removed the strict error check. this can be added once the
confidence level is higher and this flow is accounted for. until then I will
focus on the addition parts.
* DistributedZkUpdateProcessor will call setupRequest twice. this is probably a
minor nuisance for some future improvement PR.
* finding the code very hard to read I took the decision to remove one variable
that is not really needed (the updateCommand), this change is purely cosmetic
and I can revert it if it adds too much noise to the current patch.
> ShardSplitTest NPE
> --
>
> Key: SOLR-7609
> URL: https://issues.apache.org/jira/browse/SOLR-7609
> Project: Solr
> Issue Type: Bug
>Reporter: Steven Rowe
>Priority: Minor
> Attachments: ShardSplitTest.NPE.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm guessing this is a test bug, but the seed doesn't reproduce for me (tried
> on the same Linux machine it occurred on and on OS X):
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=ShardSplitTest
> -Dtests.method=test -Dtests.seed=9318DDA46578ECF9 -Dtests.slow=true
> -Dtests.locale=is -Dtests.timezone=America/St_Vincent -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR 55.8s J6 | ShardSplitTest.test <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([9318DDA46578ECF9:1B4CE27ECB848101]:0)
>[junit4]> at
> org.apache.solr.cloud.ShardSplitTest.logDebugHelp(ShardSplitTest.java:547)
>[junit4]> at
> org.apache.solr.cloud.ShardSplitTest.checkDocCountsAndShardStates(ShardSplitTest.java:438)
>[junit4]> at
> org.apache.solr.cloud.ShardSplitTest.splitByUniqueKeyTest(ShardSplitTest.java:222)
>[junit4]> at
> org.apache.solr.cloud.ShardSplitTest.test(ShardSplitTest.java:84)
>[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
>[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
>[junit4]> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Line 547 of {{ShardSplitTest.java}} is:
> {code:java}
> idVsVersion.put(document.getFieldValue("id").toString(),
> document.getFieldValue("_version_").toString());
> {code}
> Skimming the code, it's not obvious what could be null.
--
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] tflobbe commented on pull request #1512: SOLR-16731: Use the right cluster property for determining if TLS is enabled
tflobbe commented on PR #1512: URL: https://github.com/apache/solr/pull/1512#issuecomment-1492448537 It used to work before [this change](https://github.com/apache/solr/pull/460/files#diff-83579b1681fbe3ea47f7340796963b034594921405afb41c62d9415f52f5adcfR360) -- 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] HoustonPutman commented on pull request #1501: SOLR-16713: Replace Guava usages with pure Java (part 2)
HoustonPutman commented on PR #1501: URL: https://github.com/apache/solr/pull/1501#issuecomment-1492444801 > so added a simple helper to StrUtils to do that conversion. Ahh ok I get that, but why do all of the readers need to be wrapped by `BufferedReader` first? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16507) Remove NodeStateProvider & Snitch
[ https://issues.apache.org/jira/browse/SOLR-16507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707393#comment-17707393 ] ASF subversion and git services commented on SOLR-16507: Commit 9fa1eba9a3ae204d0540d6fbc97a0b185d2ae385 in solr's branch refs/heads/main from vinayak hegde [ https://gitbox.apache.org/repos/asf?p=solr.git;h=9fa1eba9a3a ] SOLR-16507: SplitShardCmd shouldn't use NodeStateProvider (#1485) Objective is to limit use of NodeStateProvider to where it's best. > Remove NodeStateProvider & Snitch > - > > Key: SOLR-16507 > URL: https://issues.apache.org/jira/browse/SOLR-16507 > Project: Solr > Issue Type: Task >Reporter: David Smiley >Priority: Major > Labels: newdev > Time Spent: 1.5h > Remaining Estimate: 0h > > The NodeStateProvider is a relic relating to the old autoscaling framework > that was removed in Solr 9. The only remaining usage of it is for > SplitShardCmd to check the disk space. For this, it could use the metrics > api. > I think we'll observe that Snitch and other classes in > org.apache.solr.common.cloud.rule can be removed as well, as it's related to > NodeStateProvider. > Only > org.apache.solr.cluster.placement.impl.AttributeFetcherImpl#getMetricSnitchTag > and org.apache.solr.cluster.placement.impl.NodeMetricImpl refer to some > constants in the code to be removed. Those constants could move out, > consolidated somewhere we think is appropriate. -- 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] dsmiley merged pull request #1485: SOLR-16507: Remove NodeStateProvider & Snitch
dsmiley merged PR #1485: URL: https://github.com/apache/solr/pull/1485 -- 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] stillalex commented on pull request #1504: SOLR-7609 ShardSplitTest NPE investigation
stillalex commented on PR #1504: URL: https://github.com/apache/solr/pull/1504#issuecomment-1492441639 I have pushed a tentative patch for review and more importantly for discussion. I have ran this test extensively (hundreds of beast jobs) and it looks like this is the way to go, all 'add' exceptions are gone once the isLeader flag is updated. BUT I am not completely convinced this is the correct patch. possibly something could be made better in the DistributedZkUpdateProcessor area instead (where a lot of leader calculations are being made but the result is not correct in this edge case). While I am still evaluating a patch for DistributedZkUpdateProcessor, I would love some feedback on the observations so far. Together with the patch I have added a check which will not allow additions with no version. this is now consistent with the delete flows. although I must admit I am confused by the fact that this check was missing on this execution path, while the delete path had this from at least 8 years ago. Other points - in the current test, there are a few operations (add and deletes) that run parallel to the split operation. these can fail and this is where the bug is. because the exceptions are not correctly accounted for, the NPE popped up at a weird place. I added tracking and assertions on this part too (except for deletes, see below) - deletes can also cause exceptions, I don't have a good handle on how to fix this, so I removed the strict error check. this can be added once the confidence level is higher and this flow is accounted for. until then I will focus on the addition parts. - DistributedZkUpdateProcessor will call setupRequest twice. this is probably a minor nuisance for some future improvement PR. - finding the code very hard to read I took the decision to remove one variable that is not really needed (the `updateCommand`), this change is purely cosmetic and I can revert it if it adds too much noise to the current patch. -- 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 commented on pull request #1501: SOLR-16713: Replace Guava usages with pure Java (part 2)
risdenk commented on PR #1501: URL: https://github.com/apache/solr/pull/1501#issuecomment-1492432576 > Why do we want to get rid of `IOUtils.toString()` This is a specific version of IOUtils.toString() specifically one that deals with Java Reader. Basically limits usage of commons-io. Guava and commons-io both had methods converting a Java Reader to a String so added a simple helper to StrUtils to do that conversion. -- 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] HoustonPutman commented on pull request #1501: SOLR-16713: Replace Guava usages with pure Java (part 2)
HoustonPutman commented on PR #1501: URL: https://github.com/apache/solr/pull/1501#issuecomment-1492423646 Why do we want to get rid of `IOUtils.toString()` -- 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] tflobbe opened a new pull request, #1512: SOLR-16731: Use the right cluster property for determining if TLS is enabled
tflobbe opened a new pull request, #1512: URL: https://github.com/apache/solr/pull/1512 Note that this only changes what's displayed by `SystemInfoHandler` -- 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-16713) Replace Guava usages with pure Java
[ https://issues.apache.org/jira/browse/SOLR-16713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16713: Description: Guava is used in a variety of places that can be simplified especially with Java streams. * Preconditions -> Objects * Strings.isNullOrEmpty -> Simple helper method on StrUtils * Maps/ImmutableMap -> Java Map * Lists/ImmutableList -> Java List * Sets/ImmutableSet/ImmutableSortedSet -> Java Set * Collections2/Iterables/Iterators/ObjectArrays -> Java Stream * Guava cache -> Caffeine cache This ends up removing the Guava dependency from 4 build.gradle files: * modules/analytics * modules/sql * modules/gcs-repository - test * solrj - test Second pass cleans up * com.google.common.base.Throwables * com.google.common.collect.ImmutableMap * com.google.common.collect.** * com.google.common.io.** (and consequently org.apache.commons.io.IOUtils#toString(java.io.Reader) since its the same usage) This ends up removing Guava dependency from * test-framework * solrj-zookeeper - test was: Guava is used in a variety of places that can be simplified especially with Java streams. * Preconditions -> Objects * Strings.isNullOrEmpty -> Simple helper method on StrUtils * Maps/ImmutableMap -> Java Map * Lists/ImmutableList -> Java List * Sets/ImmutableSet/ImmutableSortedSet -> Java Set * Collections2/Iterables/Iterators/ObjectArrays -> Java Stream * Guava cache -> Caffeine cache This ends up removing the Guava dependency from 4 build.gradle files: * modules/analytics * modules/sql * modules/gcs-repository - test * solrj - test > Replace Guava usages with pure Java > > > Key: SOLR-16713 > URL: https://issues.apache.org/jira/browse/SOLR-16713 > Project: Solr > Issue Type: Task >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Minor > Fix For: main (10.0), 9.3 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > Guava is used in a variety of places that can be simplified especially with > Java streams. > * Preconditions -> Objects > * Strings.isNullOrEmpty -> Simple helper method on StrUtils > * Maps/ImmutableMap -> Java Map > * Lists/ImmutableList -> Java List > * Sets/ImmutableSet/ImmutableSortedSet -> Java Set > * Collections2/Iterables/Iterators/ObjectArrays -> Java Stream > * Guava cache -> Caffeine cache > This ends up removing the Guava dependency from 4 build.gradle files: > * modules/analytics > * modules/sql > * modules/gcs-repository - test > * solrj - test > > Second pass cleans up > * com.google.common.base.Throwables > * com.google.common.collect.ImmutableMap > * com.google.common.collect.** > * com.google.common.io.** (and consequently > org.apache.commons.io.IOUtils#toString(java.io.Reader) since its the same > usage) > This ends up removing Guava dependency from > * test-framework > * solrj-zookeeper - test -- 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-16729) NP because roles is null
[
https://issues.apache.org/jira/browse/SOLR-16729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved SOLR-16729.
Resolution: Duplicate
See SOLR-16730 for patch
> NP because roles is null
>
>
> Key: SOLR-16729
> URL: https://issues.apache.org/jira/browse/SOLR-16729
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server, SolrCloud
>Affects Versions: 9.2
>Reporter: Thomas Wöckinger
>Assignee: Jan Høydahl
>Priority: Major
>
> When using SolrCloud with following simple security.json
>
> {code:java}
> {
> "authentication": {
> "class": "solr.BasicAuthPlugin",
> "blockUnknown": true,
> "credentials": {
> "blue": ""
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{
> "name": "all",
> "role": "admin"
> }],
> "user-role": {
> "blue": "admin"
> }
> }
> }
> {code}
>
> After login and clicking on *Cloud* in Admin UI following exception shows up
> in the logs (see next comment)
--
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 commented on pull request #1511: SOLR-16730: Exclude username, roles and permissions for inter-node requests to SystemInfoHandler
janhoy commented on PR #1511: URL: https://github.com/apache/solr/pull/1511#issuecomment-1492398190 According to RBAP api, the `[getUserRoles()](https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPluginBase.java#L371)` call should not return null but empty set. So I think that can be fixed too, by making [this](https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L65) null-safe. After coding Kotlin for a few years I really miss its not-null-by-default! Basically, this looks like a decent solution. -- 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-16729) NP because roles is null
[
https://issues.apache.org/jira/browse/SOLR-16729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707384#comment-17707384
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-16729:
--
I didn't see this Jira issue and created SOLR-16730. PTAL at
https://github.com/apache/solr/pull/1511
> NP because roles is null
>
>
> Key: SOLR-16729
> URL: https://issues.apache.org/jira/browse/SOLR-16729
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server, SolrCloud
>Affects Versions: 9.2
>Reporter: Thomas Wöckinger
>Assignee: Jan Høydahl
>Priority: Major
>
> When using SolrCloud with following simple security.json
>
> {code:java}
> {
> "authentication": {
> "class": "solr.BasicAuthPlugin",
> "blockUnknown": true,
> "credentials": {
> "blue": ""
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{
> "name": "all",
> "role": "admin"
> }],
> "user-role": {
> "blue": "admin"
> }
> }
> }
> {code}
>
> After login and clicking on *Cloud* in Admin UI following exception shows up
> in the logs (see next comment)
--
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] tflobbe commented on a diff in pull request #1359: SOLR-16658 List of permissions returned to Admin UI is not complete
tflobbe commented on code in PR #1359:
URL: https://github.com/apache/solr/pull/1359#discussion_r1154757112
##
solr/core/src/java/org/apache/solr/handler/admin/SystemInfoHandler.java:
##
@@ -339,7 +341,10 @@ public SimpleOrderedMap
getSecurityInfo(SolrQueryRequest req) {
RuleBasedAuthorizationPluginBase rbap =
(RuleBasedAuthorizationPluginBase) auth;
Set roles = rbap.getUserRoles(req.getUserPrincipal());
info.add("roles", roles);
-info.add("permissions", rbap.getPermissionNamesForRoles(roles));
+info.add(
+"permissions",
+rbap.getPermissionNamesForRoles(
+Stream.concat(roles.stream(), Stream.of("*",
null)).collect(Collectors.toSet(;
Review Comment:
Ugh, sorry, I created SOLR-16730
--
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-16731) "tls" key incorrect in SystemInfoHandler requests
[
https://issues.apache.org/jira/browse/SOLR-16731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe updated SOLR-16731:
-
Affects Version/s: 9.0
> "tls" key incorrect in SystemInfoHandler requests
> -
>
> Key: SOLR-16731
> URL: https://issues.apache.org/jira/browse/SOLR-16731
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.0, 8.11.2, 9.1, 9.2, 9.1.1
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Minor
>
> {{SystemInfoHandler}} tries to display if TLS is enabled or not for a
> cluster, but in order to do this it checks the cluster property "base_url".
> This is not the right property to look at, should be "urlScheme"
--
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-16731) "tls" key incorrect in SystemInfoHandler requests
[
https://issues.apache.org/jira/browse/SOLR-16731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707382#comment-17707382
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-16731:
--
This seems to have been introduced with SOLR-15587
> "tls" key incorrect in SystemInfoHandler requests
> -
>
> Key: SOLR-16731
> URL: https://issues.apache.org/jira/browse/SOLR-16731
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.11.2, 9.1, 9.2, 9.1.1
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Minor
>
> {{SystemInfoHandler}} tries to display if TLS is enabled or not for a
> cluster, but in order to do this it checks the cluster property "base_url".
> This is not the right property to look at, should be "urlScheme"
--
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-16731) "tls" key incorrect in SystemInfoHandler requests
Tomas Eduardo Fernandez Lobbe created SOLR-16731:
Summary: "tls" key incorrect in SystemInfoHandler requests
Key: SOLR-16731
URL: https://issues.apache.org/jira/browse/SOLR-16731
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 9.1.1, 9.2, 9.1, 8.11.2
Reporter: Tomas Eduardo Fernandez Lobbe
{{SystemInfoHandler}} tries to display if TLS is enabled or not for a cluster,
but in order to do this it checks the cluster property "base_url". This is not
the right property to look at, should be "urlScheme"
--
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] tflobbe opened a new pull request, #1511: SOLR-16730: Exclude username, roles and permissions for inter-node requests to SystemInfoHandler
tflobbe opened a new pull request, #1511:
URL: https://github.com/apache/solr/pull/1511
This PR addresses `SOLR-16730` by completely skipping including the
username, roles and permissions when the request is an inter-node request to
`SystemInfoHandler`.
Having this part alone:
```
if (roles == null) {
info.add("permissions", Set.of());
}
```
should be enough to handle the NPE described in the Jira issue, but I think
it may be better to just skip this section for internal requests, since the
data displayed is unrelated to the user that issues the request.
--
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 #483: Servicemonitor for prometheus exporter is referring to cluster port instead of metrics pod port
HoustonPutman commented on issue #483: URL: https://github.com/apache/solr-operator/issues/483#issuecomment-1492374530 I have a patch that I _think_ should work: https://github.com/apache/solr-operator/pull/539. Would someone be willing to try out this fix in their cluster? Steps to try it: 1. Checkout the v0.6.0 release 2. Copy this one line change 3. Run `make docker-build`, then upload to docker somewhere 4. Update your Solr Operator to use this new image 5. Delete the prometheus exporter service just to make sure the annotation is removed: `kubectl delete service -solr-metrics` 6. Wait for it to come back and see if Prometheus is happier! -- 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 #1359: SOLR-16658 List of permissions returned to Admin UI is not complete
janhoy commented on code in PR #1359:
URL: https://github.com/apache/solr/pull/1359#discussion_r1154744612
##
solr/core/src/java/org/apache/solr/handler/admin/SystemInfoHandler.java:
##
@@ -339,7 +341,10 @@ public SimpleOrderedMap
getSecurityInfo(SolrQueryRequest req) {
RuleBasedAuthorizationPluginBase rbap =
(RuleBasedAuthorizationPluginBase) auth;
Set roles = rbap.getUserRoles(req.getUserPrincipal());
info.add("roles", roles);
-info.add("permissions", rbap.getPermissionNamesForRoles(roles));
+info.add(
+"permissions",
+rbap.getPermissionNamesForRoles(
+Stream.concat(roles.stream(), Stream.of("*",
null)).collect(Collectors.toSet(;
Review Comment:
https://issues.apache.org/jira/browse/SOLR-16729
--
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 pull request, #539: Remove port annotation from PrometheusExporter service
HoustonPutman opened a new pull request, #539: URL: https://github.com/apache/solr-operator/pull/539 fixes #483 I think that the Prometheus server will use the port that the service has if none is provided, so this should fix any issues we are seeing. I'd love to see someone try this out though, since its hard to test without a prometheus server already setup. -- 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-16730) NPE in SystemInfoHandler for inter-node requests
[
https://issues.apache.org/jira/browse/SOLR-16730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707369#comment-17707369
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-16730:
--
I believe this was introduced in SOLR-16658
> NPE in SystemInfoHandler for inter-node requests
>
>
> Key: SOLR-16730
> URL: https://issues.apache.org/jira/browse/SOLR-16730
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.2
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
>
> This will happen when you are using PKIAuthenticationPlugin for internal
> requests and you use RuleBasedAuthorizationPlugin.
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.solr.handler.admin.SystemInfoHandler.getSecurityInfo(SystemInfoHandler.java:347)
> at
> org.apache.solr.handler.admin.SystemInfoHandler.handleRequestBody(SystemInfoHandler.java:155)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:224)
> at
> org.apache.solr.handler.admin.InfoHandler.handle(InfoHandler.java:94)
> at
> org.apache.solr.handler.admin.InfoHandler.handleRequestBody(InfoHandler.java:82)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:224)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:929)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:877)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:548)
> at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:252)
> at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:220)
> at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:257)
> at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:227)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:215)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:197)
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:578)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1570)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:221)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1383)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:228)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:141)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)
> {noformat}
--
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] HoustonPutman opened a new issue, #538: Make PodDisruptionBudget an optional feature
HoustonPutman opened a new issue, #538: URL: https://github.com/apache/solr-operator/issues/538 The PDB was added in: https://github.com/apache/solr-operator/issues/471 Not all users are going to want to use a `PodDisruptionBudget` when running Solr. The feature should be able to be disabled/enabled via the SolrCloud CRD. When looking at https://github.com/apache/solr-operator/issues/471, there are other options we might want to add like PDBs per-pod. So whatever field we add to the CRD should be expandable to customize other parts of the PDB creation/management. -- 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
[jira] [Created] (SOLR-16730) NPE in SystemInfoHandler for inter-node requests
Tomas Eduardo Fernandez Lobbe created SOLR-16730:
Summary: NPE in SystemInfoHandler for inter-node requests
Key: SOLR-16730
URL: https://issues.apache.org/jira/browse/SOLR-16730
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 9.2
Reporter: Tomas Eduardo Fernandez Lobbe
Assignee: Tomas Eduardo Fernandez Lobbe
This will happen when you are using PKIAuthenticationPlugin for internal
requests and you use RuleBasedAuthorizationPlugin.
{noformat}
java.lang.NullPointerException
at
org.apache.solr.handler.admin.SystemInfoHandler.getSecurityInfo(SystemInfoHandler.java:347)
at
org.apache.solr.handler.admin.SystemInfoHandler.handleRequestBody(SystemInfoHandler.java:155)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:224)
at org.apache.solr.handler.admin.InfoHandler.handle(InfoHandler.java:94)
at
org.apache.solr.handler.admin.InfoHandler.handleRequestBody(InfoHandler.java:82)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:224)
at
org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:929)
at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:877)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:548)
at
org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:252)
at
org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:220)
at
org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:257)
at
org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:227)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:215)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:197)
at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:578)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1570)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:221)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1383)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)
at
org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:228)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:141)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)
{noformat}
--
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-16728) ClassCastException while creating new collection using JDK17
[
https://issues.apache.org/jira/browse/SOLR-16728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707364#comment-17707364
]
Houston Putman commented on SOLR-16728:
---
So I don't think this is related?
The classloading issues mentioned have to do with
{{org.eclipse.jetty.alpn.client}} which is in the
{{org.eclipse.jetty:jetty-alpn-client}} library. We get this dependency in
solr-core and solrj transitively through {{org.eclipse.jetty:jetty-client}}.
The Jetty server libraries don't use {{org.eclipse.jetty:jetty-client}}, so
there is no reason that {{org.eclipse.jetty:jetty-alpn-client}} would need to
be in {{server/lib}} or {{server/lib/ext}}. Its packaged in
{{server/solr-webapp/webapp/WEB-INF/lib}}, because its purely a solr-core/solrj
dependency.
I checked and this is also the case in Solr 9.1.1.
Just to make sure, are you using an older version of
{{server/contexts/solr-jetty-context.xml}}? If so this will not be the only
error you face, and you should definitely use the new version.
> ClassCastException while creating new collection using JDK17
>
>
> Key: SOLR-16728
> URL: https://issues.apache.org/jira/browse/SOLR-16728
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server, SolrCloud
>Affects Versions: 9.2
>Reporter: Thomas Wöckinger
>Priority: Critical
>
> Creating a new collection using CollectionAPI results in following error:
> 2023-03-31T08:22:34.574888544Z 2023-03-31 08:22:34.573 WARN
> (httpShardExecutor-5-thread-3) [] o.e.j.i.ManagedSelector Could not accept
> java.nio.channels.SocketChannel[closed]: java.lang.ClassCastException: class
> org.eclipse.jetty.alpn.client.ALPNClientConnection cannot be cast to class
> org.eclipse.jetty.alpn.client.ALPNClientConnection
> (org.eclipse.jetty.alpn.client.ALPNClientConnection is in unnamed module of
> loader org.eclipse.jetty.start.Classpath$Loader @1f89ab83;
> org.eclipse.jetty.alpn.client.ALPNClientConnection is in unnamed module of
> loader org.eclipse.jetty.webapp.WebAppClassLoader @757f675c)
>
> Tested with:
> Red Hat, Inc. OpenJDK 64-Bit Server VM 17.0.6 17.0.6+10-LTS
> Solr started in cloude mode with one node and embedded zookeeper
> /opt/solr/bin/solr start -c -Dsolr.ssl.checkPeerName=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
[GitHub] [solr] stillalex commented on pull request #1504: ShardSplitTest flakiness investigation
stillalex commented on PR #1504: URL: https://github.com/apache/solr/pull/1504#issuecomment-1492285957 There is another weird error I saw while leaving this to run overnight. there are possibly more races, I will focus my proposal to the most common one, the doc addition (will be posting an update shortly). ``` > java.lang.AssertionError: Errors present while concurrently adding and removing docs [Error from server at http://127.0.0.1:55407/gne/mj/collection1_shard1_replica_n1: Async exception during distributed update: Error from server at http://127.0.0.1:55407/gne/mj/collection1_shard1_0_replica_n9/update?update.distrib=FROMLEADER&distrib.from=http%3A%2F%2F127.0.0.1%3A55407%2Fgne%2Fmj%2Fcollection1_shard1_replica_n1%2F&distrib.from.parent=shard1&wt=javabin&version=2: Request says it is coming from parent shard leader but we are in active state] > at __randomizedtesting.SeedInfo.seed([2BF99011CE0D3FCF:A3ADAFCB60F15237]:0) > at org.junit.Assert.fail(Assert.java:89) > at org.junit.Assert.assertTrue(Assert.java:42) > at org.apache.solr.cloud.api.collections.ShardSplitTest.splitByUniqueKeyTest(ShardSplitTest.java:939) > at org.apache.solr.cloud.api.collections.ShardSplitTest.test(ShardSplitTest.java:110) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1758) > at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:946) > at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:982) > at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:996) > at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1164) > at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1135) > at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:80) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.apache.lucene.tests.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:44) > at org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43) > at org.apache.lucene.tests.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:45) > at org.apache.lucene.tests.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:60) > at org.apache.lucene.tests.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:44) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:390) > at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:843) > at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:490) > at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:955) > at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:840) > at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:891) > at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:902) > at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43) > at org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43) > at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:80) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.apache.lucene.tests.util
[jira] [Updated] (SOLR-16393) Cosmetic improvements and migration to JAX-RS (alias, alias-prop CRUD APIs)
[
https://issues.apache.org/jira/browse/SOLR-16393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-16393:
---
Description:
As mentioned on SOLR-15781, the v2 API currently has an experimental
designation, and the community has expressed an interest in using this period
to update our v2 endpoints to be more REST-ful and consistent. The current
plan is to follow the specific changes laid out in [this
spreadsheet|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing],
though of course nothing there is set in stone and there are still warts to be
worked out.
While we're touching the code for these endpoints, we should also convert them
to JAX-RS framework definitions. (This was initially tracked as a separate
effort - see SOLR-16370 - but the edit that were required ended up overlapping
so significantly with the "cosmetic" improvements here that in practice it
almost always makes sense to do the two together.)
This ticket plans to tackle making the changes required for Solr's alias and
alias-prop CRUD APIs. These are described in detail in the spreadsheet linked
above, but are summarized in the table below for convenience and easier
tracking.
||API Name||Original Form||Desired Form||Status||Volunteer||
|-List Alias-|-GET /api/cluster/aliases-|-GET /api/aliases-|-Finished-|-Alex-|
|Create Alias|POST /api/collections \{"create-alias": \{...\}\}|POST
/api/aliases \{...\}|Open|Jason|
|-Delete Alias-|-POST /api/collections \{"delete-alias": \{...\}\}-|-DELETE
/api/aliases/aliasName-|-Finished-|-Jason-|
|-Set Alias Property-|-POST /api/collections \{"set-alias-property":
\{...\}\}-|-PUT /api/aliases/aliasName/properties/propName \{"value":
"someVal"\}-|-Finished-|-Alex-|
|-Delete Alias Property-|-POST /api/collections \{"set-alias-property":
\{"propName": ""\}\}-|-DELETE
/api/aliases/aliasName/properties/propName-|-Finished-|-Alex-|
was:
As mentioned on SOLR-15781, the v2 API currently has an experimental
designation, and the community has expressed an interest in using this period
to update our v2 endpoints to be more REST-ful and consistent. The current
plan is to follow the specific changes laid out in [this
spreadsheet|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing],
though of course nothing there is set in stone and there are still warts to be
worked out.
While we're touching the code for these endpoints, we should also convert them
to JAX-RS framework definitions. (This was initially tracked as a separate
effort - see SOLR-16370 - but the edit that were required ended up overlapping
so significantly with the "cosmetic" improvements here that in practice it
almost always makes sense to do the two together.)
This ticket plans to tackle making the changes required for Solr's alias and
alias-prop CRUD APIs. These are described in detail in the spreadsheet linked
above, but are summarized in the table below for convenience and easier
tracking.
||API Name||Original Form||Desired Form||Status||Volunteer||
|-List Alias-|-GET /api/cluster/aliases-|-GET /api/aliases-|-Finished-|-Alex-|
|Create Alias|POST /api/collections \{"create-alias": \{...\}\}|POST
/api/aliases {...}|Open|Jason|
|-Delete Alias-|-POST /api/collections \{"delete-alias": \{...\}\}-|-DELETE
/api/aliases/aliasName-|-Finished-|-Jason-|
|-Set Alias Property-|-POST /api/collections \{"set-alias-property":
\{...\}\}-|-PUT /api/aliases/aliasName/properties/propName {"value":
"someVal"}-|-Finished-|-Alex-|
|-Delete Alias Property-|-POST /api/collections \{"set-alias-property":
\{"propName": ""\}\}-|-DELETE
/api/aliases/aliasName/properties/propName-|-Finished-|-Alex-|
> Cosmetic improvements and migration to JAX-RS (alias, alias-prop CRUD APIs)
> ---
>
> Key: SOLR-16393
> URL: https://issues.apache.org/jira/browse/SOLR-16393
> Project: Solr
> Issue Type: Sub-task
> Components: v2 API
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Major
> Labels: newdev
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> As mentioned on SOLR-15781, the v2 API currently has an experimental
> designation, and the community has expressed an interest in using this period
> to update our v2 endpoints to be more REST-ful and consistent. The current
> plan is to follow the specific changes laid out in [this
> spreadsheet|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing],
> though of course nothing there is set in stone and there are still warts to
> be worked out.
> While we're touching the code for these endpoints, we should also convert
> them to JAX-RS framework definit
[jira] [Updated] (SOLR-16393) Cosmetic improvements and migration to JAX-RS (alias, alias-prop CRUD APIs)
[
https://issues.apache.org/jira/browse/SOLR-16393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-16393:
---
Description:
As mentioned on SOLR-15781, the v2 API currently has an experimental
designation, and the community has expressed an interest in using this period
to update our v2 endpoints to be more REST-ful and consistent. The current
plan is to follow the specific changes laid out in [this
spreadsheet|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing],
though of course nothing there is set in stone and there are still warts to be
worked out.
While we're touching the code for these endpoints, we should also convert them
to JAX-RS framework definitions. (This was initially tracked as a separate
effort - see SOLR-16370 - but the edit that were required ended up overlapping
so significantly with the "cosmetic" improvements here that in practice it
almost always makes sense to do the two together.)
This ticket plans to tackle making the changes required for Solr's alias and
alias-prop CRUD APIs. These are described in detail in the spreadsheet linked
above, but are summarized in the table below for convenience and easier
tracking.
||API Name||Original Form||Desired Form||Status||Volunteer||
|-List Alias-|-GET /api/cluster/aliases-|-GET /api/aliases-|-Finished-|-Alex-|
|Create Alias|POST /api/collections \{"create-alias": \{...\}\}|POST
/api/aliases {...}|Open|Jason|
|-Delete Alias-|-POST /api/collections \{"delete-alias": \{...\}\}-|-DELETE
/api/aliases/aliasName-|-Finished-|-Jason-|
|-Set Alias Property-|-POST /api/collections \{"set-alias-property":
\{...\}\}-|-PUT /api/aliases/aliasName/properties/propName {"value":
"someVal"}-|-Finished-|-Alex-|
|-Delete Alias Property-|-POST /api/collections \{"set-alias-property":
\{"propName": ""\}\}-|-DELETE
/api/aliases/aliasName/properties/propName-|-Finished-|-Alex-|
was:
As mentioned on SOLR-15781, the v2 API currently has an experimental
designation, and the community has expressed an interest in using this period
to update our v2 endpoints to be more REST-ful and consistent. The current
plan is to follow the specific changes laid out in [this
spreadsheet|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing],
though of course nothing there is set in stone and there are still warts to be
worked out.
While we're touching the code for these endpoints, we should also convert them
to JAX-RS framework definitions. (This was initially tracked as a separate
effort - see SOLR-16370 - but the edit that were required ended up overlapping
so significantly with the "cosmetic" improvements here that in practice it
almost always makes sense to do the two together.)
This ticket plans to tackle making the changes required for Solr's alias and
alias-prop CRUD APIs. These are described in detail in the spreadsheet linked
above, but are summarized in the table below for convenience and easier
tracking.
||API Name||Original Form||Desired Form||Status||Volunteer||
|-List Alias-|-GET /api/cluster/aliases-|-GET /api/aliases-|-Finished-|-Alex-|
|Create Alias|POST /api/collections \{"create-alias": \{...\}\}|POST
/api/aliases {...}|Open|Jason|
|Delete Alias|POST /api/collections \{"delete-alias": \{...\}\}|DELETE
/api/aliases/aliasName|Open|Jason|
|Set Alias Property|POST /api/collections \{"set-alias-property": \{...\}\}|PUT
/api/aliases/aliasName/properties/propName {"value": "someVal"}|Open|Alex|
|Delete Alias Property|POST /api/collections \{"set-alias-property":
\{"propName": ""\}\}|DELETE
/api/aliases/aliasName/properties/propName|Open|Alex|
> Cosmetic improvements and migration to JAX-RS (alias, alias-prop CRUD APIs)
> ---
>
> Key: SOLR-16393
> URL: https://issues.apache.org/jira/browse/SOLR-16393
> Project: Solr
> Issue Type: Sub-task
> Components: v2 API
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Major
> Labels: newdev
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> As mentioned on SOLR-15781, the v2 API currently has an experimental
> designation, and the community has expressed an interest in using this period
> to update our v2 endpoints to be more REST-ful and consistent. The current
> plan is to follow the specific changes laid out in [this
> spreadsheet|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing],
> though of course nothing there is set in stone and there are still warts to
> be worked out.
> While we're touching the code for these endpoints, we should also convert
> them to JAX-RS framework definitions. (This was initially tracked as a
> sepa
[jira] [Commented] (SOLR-16728) ClassCastException while creating new collection using JDK17
[
https://issues.apache.org/jira/browse/SOLR-16728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707357#comment-17707357
]
Kevin Risden commented on SOLR-16728:
-
FYI [~houston]
I don't know if this is specifically related to SOLR-15955 upgrading Jetty or
maybe related to SOLR-16158 where some of the jars were moved around.
I see
https://github.com/apache/solr/commit/a18f5b3c7cf#diff-4a5004f51d5d785e4559ac42bfe2aa30af4a1f3e3df2985ab2bc0ddc05b184fdL83
that these dependencies changed:
{code:java}
implementation 'org.eclipse.jetty:jetty-alpn-server'
runtimeOnly('org.eclipse.jetty:jetty-alpn-java-server', {
exclude group: "org.eclipse.jetty.alpn", module: "alpn-api"
})
jettyClientImplementation('org.eclipse.jetty:jetty-http')
{code}
not sure if thats related or not. It looksl ike some of these need to be in the
server WEBINF lib maybe?
> ClassCastException while creating new collection using JDK17
>
>
> Key: SOLR-16728
> URL: https://issues.apache.org/jira/browse/SOLR-16728
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server, SolrCloud
>Affects Versions: 9.2
>Reporter: Thomas Wöckinger
>Priority: Critical
>
> Creating a new collection using CollectionAPI results in following error:
> 2023-03-31T08:22:34.574888544Z 2023-03-31 08:22:34.573 WARN
> (httpShardExecutor-5-thread-3) [] o.e.j.i.ManagedSelector Could not accept
> java.nio.channels.SocketChannel[closed]: java.lang.ClassCastException: class
> org.eclipse.jetty.alpn.client.ALPNClientConnection cannot be cast to class
> org.eclipse.jetty.alpn.client.ALPNClientConnection
> (org.eclipse.jetty.alpn.client.ALPNClientConnection is in unnamed module of
> loader org.eclipse.jetty.start.Classpath$Loader @1f89ab83;
> org.eclipse.jetty.alpn.client.ALPNClientConnection is in unnamed module of
> loader org.eclipse.jetty.webapp.WebAppClassLoader @757f675c)
>
> Tested with:
> Red Hat, Inc. OpenJDK 64-Bit Server VM 17.0.6 17.0.6+10-LTS
> Solr started in cloude mode with one node and embedded zookeeper
> /opt/solr/bin/solr start -c -Dsolr.ssl.checkPeerName=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
[jira] [Assigned] (SOLR-16729) NP because roles is null
[
https://issues.apache.org/jira/browse/SOLR-16729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-16729:
--
Assignee: Jan Høydahl
> NP because roles is null
>
>
> Key: SOLR-16729
> URL: https://issues.apache.org/jira/browse/SOLR-16729
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server, SolrCloud
>Affects Versions: 9.2
>Reporter: Thomas Wöckinger
>Assignee: Jan Høydahl
>Priority: Major
>
> When using SolrCloud with following simple security.json
>
> {code:java}
> {
> "authentication": {
> "class": "solr.BasicAuthPlugin",
> "blockUnknown": true,
> "credentials": {
> "blue": ""
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{
> "name": "all",
> "role": "admin"
> }],
> "user-role": {
> "blue": "admin"
> }
> }
> }
> {code}
>
> After login and clicking on *Cloud* in Admin UI following exception shows up
> in the logs (see next comment)
--
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-16729) NP because roles is null
[
https://issues.apache.org/jira/browse/SOLR-16729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707334#comment-17707334
]
Jan Høydahl commented on SOLR-16729:
Moving looong trace to a comment
{noformat}
2023-03-31T08:32:48.543965474Z 2023-03-31 08:32:48.513 ERROR (qtp1895143699-29)
[] o.a.s.h.RequestHandlerBase java.lang.NullPointerException: Cannot invoke
"java.util.Set.stream()" because "roles" is null =>
java.lang.NullPointerException: Cannot invoke "java.util.Set.stream()" because
"roles" is null
2023-03-31T08:32:48.544044344Z at
org.apache.solr.handler.admin.SystemInfoHandler.getSecurityInfo(SystemInfoHandler.java:347)
2023-03-31T08:32:48.544181776Z java.lang.NullPointerException: Cannot invoke
"java.util.Set.stream()" because "roles" is null
2023-03-31T08:32:48.544195652Z at
org.apache.solr.handler.admin.SystemInfoHandler.getSecurityInfo(SystemInfoHandler.java:347)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544230099Z at
org.apache.solr.handler.admin.SystemInfoHandler.handleRequestBody(SystemInfoHandler.java:155)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544326484Z at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:224)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544339721Z at
org.apache.solr.handler.admin.InfoHandler.handle(InfoHandler.java:94)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544372897Z at
org.apache.solr.handler.admin.InfoHandler.handleRequestBody(InfoHandler.java:82)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544382977Z at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:224)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544416569Z at
org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:929)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.56225Z at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:877)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544480264Z at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:548)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544491123Z at
org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:252)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544523227Z at
org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:220)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544535316Z at
org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:257)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544560151Z at
org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:227)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544571048Z at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:215)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544595309Z at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:197)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544604831Z at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
~[jetty-servlet-10.0.13.jar:10.0.13]
2023-03-31T08:32:48.544635454Z at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
~[jetty-servlet-10.0.13.jar:10.0.13]
2023-03-31T08:32:48.544646277Z at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
~[jetty-servlet-10.0.13.jar:10.0.13]
2023-03-31T08:32:48.544673462Z at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
~[jetty-server-10.0.13.jar:10.0.13]
2023-03-31T08:32:48.544685145Z at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:578)
~[jetty-security-10.0.13.jar:10.0.13]
2023-
[jira] [Updated] (SOLR-16729) NP because roles is null
[
https://issues.apache.org/jira/browse/SOLR-16729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-16729:
---
Description:
When using SolrCloud with following simple security.json
{code:java}
{
"authentication": {
"class": "solr.BasicAuthPlugin",
"blockUnknown": true,
"credentials": {
"blue": ""
}
},
"authorization": {
"class": "solr.RuleBasedAuthorizationPlugin",
"permissions": [{
"name": "all",
"role": "admin"
}],
"user-role": {
"blue": "admin"
}
}
}
{code}
After login and clicking on *Cloud* in Admin UI following exception shows up in
the logs (see next comment)
was:
When using SolrCloud with following simple security.json
{
"authentication": {
"class": "solr.BasicAuthPlugin",
"blockUnknown": true,
"credentials": {
"blue": ""
}
},
"authorization": {
"class": "solr.RuleBasedAuthorizationPlugin",
"permissions": [
{
"name": "all",
"role": "admin"
}
],
"user-role": {
"blue": "admin"
}
}
}
After login and clicking on *Cloud* in Admin UI following exception shows up in
the logs:
2023-03-31T08:32:48.543965474Z 2023-03-31 08:32:48.513 ERROR (qtp1895143699-29)
[] o.a.s.h.RequestHandlerBase java.lang.NullPointerException: Cannot invoke
"java.util.Set.stream()" because "roles" is null =>
java.lang.NullPointerException: Cannot invoke "java.util.Set.stream()" because
"roles" is null
2023-03-31T08:32:48.544044344Z at
org.apache.solr.handler.admin.SystemInfoHandler.getSecurityInfo(SystemInfoHandler.java:347)
2023-03-31T08:32:48.544181776Z java.lang.NullPointerException: Cannot invoke
"java.util.Set.stream()" because "roles" is null
2023-03-31T08:32:48.544195652Z at
org.apache.solr.handler.admin.SystemInfoHandler.getSecurityInfo(SystemInfoHandler.java:347)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544230099Z at
org.apache.solr.handler.admin.SystemInfoHandler.handleRequestBody(SystemInfoHandler.java:155)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544326484Z at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:224)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544339721Z at
org.apache.solr.handler.admin.InfoHandler.handle(InfoHandler.java:94)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544372897Z at
org.apache.solr.handler.admin.InfoHandler.handleRequestBody(InfoHandler.java:82)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544382977Z at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:224)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544416569Z at
org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:929)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.56225Z at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:877)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544480264Z at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:548)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544491123Z at
org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:252)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544523227Z at
org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:220)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544535316Z at
org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:257)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544560151Z at
org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:227)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544571048Z at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:215)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6
[jira] [Updated] (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:all-tabpanel ] Jan Høydahl updated SOLR-16722: --- Description: Spinoff from solr operator PR [https://github.com/apache/solr-operator/issues/529] See dev@ discussion at https://lists.apache.org/thread/gvb8d36l7rnp5bzzdnp6kh79h3h9d147 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. was: 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. > 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] > See dev@ discussion at > https://lists.apache.org/thread/gvb8d36l7rnp5bzzdnp6kh79h3h9d147 > 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
[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=17707326#comment-17707326 ] Jan Høydahl commented on SOLR-16722: See [https://github.com/apache/solr-operator/issues/529] for the planned Operator changes. This Jira aims to handle the solr-side of things and make Solr more graceful in draining traffic before shutdown, and perhaps add some API for readiness state. I'll also cross-linked to the dev@ discussion in description. > 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] > See dev@ discussion at > https://lists.apache.org/thread/gvb8d36l7rnp5bzzdnp6kh79h3h9d147 > 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
[jira] [Commented] (SOLR-16441) Upgrade Jetty to 11.x
[
https://issues.apache.org/jira/browse/SOLR-16441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707296#comment-17707296
]
Kevin Risden commented on SOLR-16441:
-
[~bwahlen]
{quote}current solrj-9.2 uses jetty 10 client that is incompatible with
both{quote}
This is untrue as far as I'm aware. jetty 10 is drop in upgrade for jetty 9.x.
{quote}Can we just upgrade solrj (e.g. under different package solrj-jetty11 or
something).{quote}
no not easily today.
> Upgrade Jetty to 11.x
> -
>
> Key: SOLR-16441
> URL: https://issues.apache.org/jira/browse/SOLR-16441
> Project: Solr
> Issue Type: Improvement
> Components: Server
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Solr is currently using Jetty 9.4.x and upgrading to Jetty 10.x in
> SOLR-15955, we should look at upgrade to Jetty 11 which moves from javax to
> jakarta namespace for servlet.
>
--
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-16441) Upgrade Jetty to 11.x
[ https://issues.apache.org/jira/browse/SOLR-16441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707288#comment-17707288 ] Bernd Wahlen edited comment on SOLR-16441 at 3/31/23 3:06 PM: -- - spring boot 2.7.y uses jetty 9.4 - spring boot 3 uses jetty 11 current solrj-9.2 uses jetty 10 client that is incompatible with both working with solr in spring boot is very difficult now after solr was removed from spring data and now using solrj is also painful. https://spring.io/blog/2020/04/07/spring-data-for-apache-solr-discontinued i think solrj dependencies are manageable (most of the mentioned problems are not related to solrj). Can we just upgrade solrj (e.g. under different package solrj-jetty11 or something). Most jaba projects include only the client library and will be happy with that. was (Author: bwahlen): - spring boot 2.7.y uses jetty 9.4 - spring boot 3 uses jetty 11 current solrj-9.2 uses jetty 10 client that is incompatible with both working with solr in spring boot is very difucult now after solr is removed from spring data and now using solrj is also painful. https://spring.io/blog/2020/04/07/spring-data-for-apache-solr-discontinued i think solrj dependencies are manageable (most of the mentioned problems are not related to solrj). Can we just upgrade solrj (e.g. under different package solrj-jetty11 or something). Most jaba projects include only the client library and will be happy with that. > Upgrade Jetty to 11.x > - > > Key: SOLR-16441 > URL: https://issues.apache.org/jira/browse/SOLR-16441 > Project: Solr > Issue Type: Improvement > Components: Server >Reporter: Tomas Eduardo Fernandez Lobbe >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Solr is currently using Jetty 9.4.x and upgrading to Jetty 10.x in > SOLR-15955, we should look at upgrade to Jetty 11 which moves from javax to > jakarta namespace for servlet. > -- 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-16441) Upgrade Jetty to 11.x
[ https://issues.apache.org/jira/browse/SOLR-16441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707288#comment-17707288 ] Bernd Wahlen edited comment on SOLR-16441 at 3/31/23 3:06 PM: -- - spring boot 2.7.y uses jetty 9.4 - spring boot 3 uses jetty 11 current solrj-9.2 uses jetty 10 client that is incompatible with both working with solr in spring boot is very difficult now after solr was removed from spring data and now using solrj is also painful. https://spring.io/blog/2020/04/07/spring-data-for-apache-solr-discontinued i think solrj dependencies are manageable (most of the mentioned problems are not related to solrj). Can we just upgrade solrj (e.g. under different package solrj-jetty11 or something). Most java projects include only the client library and will be happy with that. was (Author: bwahlen): - spring boot 2.7.y uses jetty 9.4 - spring boot 3 uses jetty 11 current solrj-9.2 uses jetty 10 client that is incompatible with both working with solr in spring boot is very difficult now after solr was removed from spring data and now using solrj is also painful. https://spring.io/blog/2020/04/07/spring-data-for-apache-solr-discontinued i think solrj dependencies are manageable (most of the mentioned problems are not related to solrj). Can we just upgrade solrj (e.g. under different package solrj-jetty11 or something). Most jaba projects include only the client library and will be happy with that. > Upgrade Jetty to 11.x > - > > Key: SOLR-16441 > URL: https://issues.apache.org/jira/browse/SOLR-16441 > Project: Solr > Issue Type: Improvement > Components: Server >Reporter: Tomas Eduardo Fernandez Lobbe >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Solr is currently using Jetty 9.4.x and upgrading to Jetty 10.x in > SOLR-15955, we should look at upgrade to Jetty 11 which moves from javax to > jakarta namespace for servlet. > -- 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-16441) Upgrade Jetty to 11.x
[ https://issues.apache.org/jira/browse/SOLR-16441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707288#comment-17707288 ] Bernd Wahlen edited comment on SOLR-16441 at 3/31/23 3:05 PM: -- - spring boot 2.7.y uses jetty 9.4 - spring boot 3 uses jetty 11 current solrj-9.2 uses jetty 10 client that is incompatible with both working with solr in spring boot is very difucult now after solr is removed from spring data and now using solrj is also painful. https://spring.io/blog/2020/04/07/spring-data-for-apache-solr-discontinued i think solrj dependencies are manageable (most of the mentioned problems are not related to solrj). Can we just upgrade solrj (e.g. under different package solrj-jetty11 or something). Most jaba projects include only the client library and will be happy with that. was (Author: bwahlen): - spring boot 2.7.y uses jetty 9.4 - spring boot 3 uses jetty 11 current solrj-9.2 uses jetty 10 client that is incompatible with both working with solr in spring boot is very difucult now after solr is removed from spring data and now using solrj is also painful. https://spring.io/blog/2020/04/07/spring-data-for-apache-solr-discontinued i think solrj dependencies are manageable (most of the mentioned problems are not related to solrj). Can we just upgrade solrj (e.g. under different package solrj-jetty11 or something). Most project include only the client library and will be happy with that. > Upgrade Jetty to 11.x > - > > Key: SOLR-16441 > URL: https://issues.apache.org/jira/browse/SOLR-16441 > Project: Solr > Issue Type: Improvement > Components: Server >Reporter: Tomas Eduardo Fernandez Lobbe >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Solr is currently using Jetty 9.4.x and upgrading to Jetty 10.x in > SOLR-15955, we should look at upgrade to Jetty 11 which moves from javax to > jakarta namespace for servlet. > -- 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-16441) Upgrade Jetty to 11.x
[ https://issues.apache.org/jira/browse/SOLR-16441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707288#comment-17707288 ] Bernd Wahlen edited comment on SOLR-16441 at 3/31/23 3:04 PM: -- - spring boot 2.7.y uses jetty 9.4 - spring boot 3 uses jetty 11 current solrj-9.2 uses jetty 10 client that is incompatible with both working with solr in spring boot is very difucult now after solr is removed from spring data and now using solrj is also painful. https://spring.io/blog/2020/04/07/spring-data-for-apache-solr-discontinued i think solrj dependencies are manageable (most of the mentioned problems are not related to solrj). Can we just upgrade solrj (e.g. under different package solrj-jetty11 or something). Most project include only the client library and will be happy with that. was (Author: bwahlen): - spring boot 2.7.y uses jetty 9.4 - spring boot 3 uses jetty 11 current solrj-9.2 uses jetty 10 client that is incompatible with both working with solr in spring boot is very difucult now after solr is removed from spring data and now using solrj is also painful. https://spring.io/blog/2020/04/07/spring-data-for-apache-solr-discontinued > Upgrade Jetty to 11.x > - > > Key: SOLR-16441 > URL: https://issues.apache.org/jira/browse/SOLR-16441 > Project: Solr > Issue Type: Improvement > Components: Server >Reporter: Tomas Eduardo Fernandez Lobbe >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Solr is currently using Jetty 9.4.x and upgrading to Jetty 10.x in > SOLR-15955, we should look at upgrade to Jetty 11 which moves from javax to > jakarta namespace for servlet. > -- 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-16441) Upgrade Jetty to 11.x
[ https://issues.apache.org/jira/browse/SOLR-16441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707288#comment-17707288 ] Bernd Wahlen commented on SOLR-16441: - - spring boot 2.7.y uses jetty 9.4 - spring boot 3 uses jetty 11 current solrj-9.2 uses jetty 10 client that is incompatible with both working with solr in spring boot is very difucult now after solr is removed from spring data and now using solrj is also painful. https://spring.io/blog/2020/04/07/spring-data-for-apache-solr-discontinued > Upgrade Jetty to 11.x > - > > Key: SOLR-16441 > URL: https://issues.apache.org/jira/browse/SOLR-16441 > Project: Solr > Issue Type: Improvement > Components: Server >Reporter: Tomas Eduardo Fernandez Lobbe >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Solr is currently using Jetty 9.4.x and upgrading to Jetty 10.x in > SOLR-15955, we should look at upgrade to Jetty 11 which moves from javax to > jakarta namespace for servlet. > -- 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] HoustonPutman commented on issue #537: Slow restart of Solr Pod init_container cp-solr-xml chown
HoustonPutman commented on issue #537: URL: https://github.com/apache/solr-operator/issues/537#issuecomment-1491984499 Yeah, sounds like a good improvement! Looks like you are testing out some options, so make a PR when you are ready. -- 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] smoldenhauer-ish commented on issue #537: Slow restart of Solr Pod init_container cp-solr-xml chown
smoldenhauer-ish commented on issue #537: URL: https://github.com/apache/solr-operator/issues/537#issuecomment-1491648615 basic idea is to skip the chown if the backup directory is already writable for the solr user. -- 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 pull request #1502: SOLR-16721 Java version detection fails when `_JAVA_OPTIONS` is set
janhoy commented on PR #1502: URL: https://github.com/apache/solr/pull/1502#issuecomment-1491630140 Yep, with your example you'd get this output: ``` 8 42 ``` Agree it won't hurt adding back the head -- 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] smoldenhauer-ish opened a new issue, #537: Slow restart of Solr Pod init_container cp-solr-xml chown
smoldenhauer-ish opened a new issue, #537: URL: https://github.com/apache/solr-operator/issues/537 Solr Operator 0.6.0 In our deployments a restart of Solr Pods will take minutes up to half an hour. The init container cp-solr-xml with the command cp /tmp/solr.xml /tmp-config/solr.xml && chown -R 8983:8983 /var/solr/data/backup-restore/local-collection-backups-1 esp. the recursive chown seems to be the cause. We mitigated it a bit by cleaning up the backup volume regularly. But there are deployments with a larger number of collections (~400) and then it is still slow. ... The backup repository is a azurefile-csi storage. mailing list discussion: https://lists.apache.org/thread/tlxg38v6y81dhykycrgqw77mm2xdoqbr -- 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
[jira] [Created] (SOLR-16729) NP because roles is null
Thomas Wöckinger created SOLR-16729:
---
Summary: NP because roles is null
Key: SOLR-16729
URL: https://issues.apache.org/jira/browse/SOLR-16729
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Server, SolrCloud
Affects Versions: 9.2
Reporter: Thomas Wöckinger
When using SolrCloud with following simple security.json
{
"authentication": {
"class": "solr.BasicAuthPlugin",
"blockUnknown": true,
"credentials": {
"blue": ""
}
},
"authorization": {
"class": "solr.RuleBasedAuthorizationPlugin",
"permissions": [
{
"name": "all",
"role": "admin"
}
],
"user-role": {
"blue": "admin"
}
}
}
After login and clicking on *Cloud* in Admin UI following exception shows up in
the logs:
2023-03-31T08:32:48.543965474Z 2023-03-31 08:32:48.513 ERROR (qtp1895143699-29)
[] o.a.s.h.RequestHandlerBase java.lang.NullPointerException: Cannot invoke
"java.util.Set.stream()" because "roles" is null =>
java.lang.NullPointerException: Cannot invoke "java.util.Set.stream()" because
"roles" is null
2023-03-31T08:32:48.544044344Z at
org.apache.solr.handler.admin.SystemInfoHandler.getSecurityInfo(SystemInfoHandler.java:347)
2023-03-31T08:32:48.544181776Z java.lang.NullPointerException: Cannot invoke
"java.util.Set.stream()" because "roles" is null
2023-03-31T08:32:48.544195652Z at
org.apache.solr.handler.admin.SystemInfoHandler.getSecurityInfo(SystemInfoHandler.java:347)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544230099Z at
org.apache.solr.handler.admin.SystemInfoHandler.handleRequestBody(SystemInfoHandler.java:155)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544326484Z at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:224)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544339721Z at
org.apache.solr.handler.admin.InfoHandler.handle(InfoHandler.java:94)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544372897Z at
org.apache.solr.handler.admin.InfoHandler.handleRequestBody(InfoHandler.java:82)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544382977Z at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:224)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544416569Z at
org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:929)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.56225Z at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:877)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544480264Z at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:548)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544491123Z at
org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:252)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544523227Z at
org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:220)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544535316Z at
org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:257)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544560151Z at
org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:227)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544571048Z at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:215)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:32:48.544595309Z at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:197)
~[solr-core-9.2.0.jar:9.2.0 92c5515e2918c22513f7aa527d6c6db943150fea - houston
- 2023-03-20 20:30:42]
2023-03-31T08:3
[GitHub] [solr] alessandrobenedetti commented on a diff in pull request #1435: SOLR-16674: Introduce dense vector byte encoding
alessandrobenedetti commented on code in PR #1435: URL: https://github.com/apache/solr/pull/1435#discussion_r1154191299 ## solr/solr-ref-guide/modules/query-guide/pages/dense-vector-search.adoc: ## @@ -126,6 +126,18 @@ Accepted values: `hnsw`. Please note that the `knnAlgorithm` accepted values may change in future releases. +`vectorEncoding`:: ++ +[%autowidth,frame=none] +|=== +|Optional |Default: `FLOAT32` +|=== ++ +(advanced) Specifies the underlying encoding of the dense vector. This affects both the index and the stored fields (if enabled) Review Comment: (advanced) Specifies the underlying encoding of the dense vector elements. This affects memory/disk impact for both the indexed and stored fields (if enabled) -- 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] alessandrobenedetti commented on a diff in pull request #1435: SOLR-16674: Introduce dense vector byte encoding
alessandrobenedetti commented on code in PR #1435:
URL: https://github.com/apache/solr/pull/1435#discussion_r1154188607
##
solr/core/src/test/org/apache/solr/search/neural/KnnQParserTest.java:
##
@@ -205,6 +214,31 @@ public void correctVectorField_shouldSearchOnThatField() {
"//result/doc[3]/str[@name='id'][.='12']");
}
+ @Test
+ public void vectorByteEncodingField_shouldSearchOnThatField() {
+String vectorToSearch = "[2.0, 2.0, 1.0, 3.0]";
+
+assertQ(
+req(CommonParams.Q, "{!knn f=vector_byte_encoding topK=2}" +
vectorToSearch, "fl", "id"),
+"//result[@numFound='2']",
+"//result/doc[1]/str[@name='id'][.='2']",
+"//result/doc[2]/str[@name='id'][.='3']");
+ }
+
+ @Test
+ public void
vectorByteEncodingField_shouldNotApproximateQueryVectorValueToIntegerValues() {
+String vectorToSearch = "[7.9f, 2.9f, 1.9f, 3.9f]";
+
+// If we consider the vectors with floating values, document 7 has an
higher score than document
+// 6.
+// If instead we take only the integer part, document 6 gets an higher
score.
Review Comment:
having various if in the comment make this test difficult to read, where is
this condition?
--
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-16728) ClassCastException while creating new collection using JDK17
Thomas Wöckinger created SOLR-16728: --- Summary: ClassCastException while creating new collection using JDK17 Key: SOLR-16728 URL: https://issues.apache.org/jira/browse/SOLR-16728 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: Server, SolrCloud Affects Versions: 9.2 Reporter: Thomas Wöckinger Creating a new collection using CollectionAPI results in following error: 2023-03-31T08:22:34.574888544Z 2023-03-31 08:22:34.573 WARN (httpShardExecutor-5-thread-3) [] o.e.j.i.ManagedSelector Could not accept java.nio.channels.SocketChannel[closed]: java.lang.ClassCastException: class org.eclipse.jetty.alpn.client.ALPNClientConnection cannot be cast to class org.eclipse.jetty.alpn.client.ALPNClientConnection (org.eclipse.jetty.alpn.client.ALPNClientConnection is in unnamed module of loader org.eclipse.jetty.start.Classpath$Loader @1f89ab83; org.eclipse.jetty.alpn.client.ALPNClientConnection is in unnamed module of loader org.eclipse.jetty.webapp.WebAppClassLoader @757f675c) Tested with: Red Hat, Inc. OpenJDK 64-Bit Server VM 17.0.6 17.0.6+10-LTS Solr started in cloude mode with one node and embedded zookeeper /opt/solr/bin/solr start -c -Dsolr.ssl.checkPeerName=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
[GitHub] [solr] alessandrobenedetti commented on a diff in pull request #1435: SOLR-16674: Introduce dense vector byte encoding
alessandrobenedetti commented on code in PR #1435:
URL: https://github.com/apache/solr/pull/1435#discussion_r1154186439
##
solr/core/src/test/org/apache/solr/schema/DenseVectorFieldTest.java:
##
@@ -458,4 +574,127 @@ public void
query_functionQueryUsage_shouldThrowException() throws Exception {
deleteCore();
}
}
+
+ @Test
+ public void denseVectorField_shouldBePresentAfterAtomicUpdate() throws
Exception {
+try {
+ initCore("solrconfig.xml", "schema-densevector.xml");
+ SolrInputDocument doc = new SolrInputDocument();
+ doc.addField("id", "0");
+ doc.addField("vector", Arrays.asList(1.1, 2.2, 3.3, 4.4));
+ doc.addField("vector_byte_encoding", Arrays.asList(5, 6, 7, 8));
+ doc.addField("string_field", "test");
+
+ assertU(adoc(doc));
+ assertU(commit());
+
+ assertJQ(
+ req("q", "id:0", "fl", "*"),
+ "/response/docs/[0]/vector==[1.1,2.2,3.3,4.4]",
+ "/response/docs/[0]/vector_byte_encoding==[5,6,7,8]",
+ "/response/docs/[0]/string_field==test");
+
+ SolrInputDocument updateDoc = new SolrInputDocument();
+ updateDoc.addField("id", "0");
+ updateDoc.addField("string_field", Map.of("set", "other test"));
+ assertU(adoc(updateDoc));
+ assertU(commit());
+
+ assertJQ(
+ req("q", "id:0", "fl", "*"),
+ "/response/docs/[0]/vector==[1.1,2.2,3.3,4.4]",
+ "/response/docs/[0]/vector_byte_encoding==[5,6,7,8]",
+ "/response/docs/[0]/string_field=='other test'");
+
+} finally {
+ deleteCore();
+}
+ }
+
+ @Test
+ public void denseVectorFieldOnAtomicUpdate_shouldBeUpdatedCorrectly() throws
Exception {
+try {
+ initCore("solrconfig.xml", "schema-densevector.xml");
+ SolrInputDocument doc = new SolrInputDocument();
+ doc.addField("id", "0");
+ doc.addField("vector", Arrays.asList(1.1, 2.2, 3.3, 4.4));
+ doc.addField("vector_byte_encoding", Arrays.asList(5, 6, 7, 8));
+ doc.addField("string_field", "test");
+
+ assertU(adoc(doc));
+ assertU(commit());
+
+ assertJQ(
+ req("q", "id:0", "fl", "*"),
+ "/response/docs/[0]/vector==[1.1,2.2,3.3,4.4]",
+ "/response/docs/[0]/vector_byte_encoding==[5,6,7,8]",
+ "/response/docs/[0]/string_field==test");
+
+ SolrInputDocument updateDoc = new SolrInputDocument();
+ updateDoc.addField("id", "0");
+ updateDoc.addField("vector", Map.of("set", Arrays.asList(9.2, 2.2, 3.3,
5.2)));
+ updateDoc.addField("vector_byte_encoding", Map.of("set",
Arrays.asList(8, 3, 1, 3)));
+ assertU(adoc(updateDoc));
+ assertU(commit());
+
+ assertJQ(
+ req("q", "id:0", "fl", "*"),
+ "/response/docs/[0]/vector==[9.2,2.2,3.3,5.2]",
+ "/response/docs/[0]/vector_byte_encoding==[8,3,1,3]",
+ "/response/docs/[0]/string_field=='test'");
+
+} finally {
+ deleteCore();
+}
+ }
+
+ @Test
+ public void
denseVectorByteEncoding_shouldRaiseExceptionWithValuesOutsideBoundaries()
+ throws Exception {
+try {
+ initCore("solrconfig.xml", "schema-densevector.xml");
+ SolrInputDocument doc = new SolrInputDocument();
+ doc.addField("id", "0");
+ doc.addField("vector_byte_encoding", Arrays.asList(127.5, 6.6, 7.7,
8.8));
+
+ RuntimeException thrown =
+ assertThrows(
+ "Incorrect elements should throw an exception",
+ SolrException.class,
+ () -> {
+assertU(adoc(doc));
+ });
+
+ MatcherAssert.assertThat(
+ thrown.getCause().getMessage(),
+ is(
+ "Error while creating field
'vector_byte_encoding{type=knn_vector_byte_encoding,properties=indexed,stored}'
from value '[127.5, 6.6, 7.7, 8.8]', expected format:'[f1, f2, f3...fn]'"));
Review Comment:
isn't this message incorrect?
For byte the expected format should be '[b1, b2, b3...bn]' rather than '[f1,
f2, f3...fn]'
--
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] alessandrobenedetti commented on a diff in pull request #1435: SOLR-16674: Introduce dense vector byte encoding
alessandrobenedetti commented on code in PR #1435:
URL: https://github.com/apache/solr/pull/1435#discussion_r1154184243
##
solr/core/src/test/org/apache/solr/schema/DenseVectorFieldTest.java:
##
@@ -357,6 +452,27 @@ public void query_storedField_shouldBeReturnedInResults()
throws Exception {
}
}
+ @Test
+ public void query_vectorByteEncoded_storedField_shouldBeReturnedInResults()
throws Exception {
Review Comment:
is there also a test for the float encoding?
--
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] alessandrobenedetti commented on a diff in pull request #1435: SOLR-16674: Introduce dense vector byte encoding
alessandrobenedetti commented on code in PR #1435:
URL: https://github.com/apache/solr/pull/1435#discussion_r1154182662
##
solr/core/src/test/org/apache/solr/schema/DenseVectorFieldTest.java:
##
@@ -253,10 +332,17 @@ public void
parseVector_incorrectElement_shouldThrowException() {
*/
@Test
public void parseVector_StringArrayList_shouldParseFloatArray() {
-toTest = new DenseVectorField(3);
float[] expected = new float[] {1.1f, 2.2f, 3.3f};
+MatcherAssert.assertThat(
+toTestFloatEncoding.getVectorBuilder(Arrays.asList(1.1f, 2.2f,
3.3f)).getFloatVector(),
+is(expected));
+ }
-MatcherAssert.assertThat(toTest.parseVector(Arrays.asList("1.1", "2.2",
"3.3")), is(expected));
+ @Test
+ public void parseVector_StringArrayList_shouldParseByteArray() {
+BytesRef expected = newBytesRef(new byte[] {1, 2, 3});
+MatcherAssert.assertThat(
+toTestByteEncoding.getVectorBuilder(Arrays.asList(1, 2,
3)).getByteVector(), is(expected));
Review Comment:
should be list of string
--
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] alessandrobenedetti commented on a diff in pull request #1435: SOLR-16674: Introduce dense vector byte encoding
alessandrobenedetti commented on code in PR #1435:
URL: https://github.com/apache/solr/pull/1435#discussion_r1154182254
##
solr/core/src/test/org/apache/solr/schema/DenseVectorFieldTest.java:
##
@@ -253,10 +332,17 @@ public void
parseVector_incorrectElement_shouldThrowException() {
*/
@Test
public void parseVector_StringArrayList_shouldParseFloatArray() {
-toTest = new DenseVectorField(3);
float[] expected = new float[] {1.1f, 2.2f, 3.3f};
+MatcherAssert.assertThat(
+toTestFloatEncoding.getVectorBuilder(Arrays.asList(1.1f, 2.2f,
3.3f)).getFloatVector(),
Review Comment:
this should be a list of strings
--
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] alessandrobenedetti commented on a diff in pull request #1435: SOLR-16674: Introduce dense vector byte encoding
alessandrobenedetti commented on code in PR #1435:
URL: https://github.com/apache/solr/pull/1435#discussion_r1154179416
##
solr/core/src/test/org/apache/solr/schema/DenseVectorFieldTest.java:
##
@@ -171,57 +182,111 @@ public void parseVector_NotAList_shouldThrowException() {
"Single string value should throw an exception",
SolrException.class,
() -> {
- toTest.parseVector("string");
+ toTestFloatEncoding.getVectorBuilder("string").getFloatVector();
});
MatcherAssert.assertThat(
thrown.getMessage(),
is(
-"incorrect vector format."
-+ " The expected format is an array :'[f1,f2..f3]' where each
element f is a float"));
+"incorrect vector format. The expected format is:'[f1,f2..f3]'
where each element f is a float"));
+
+thrown =
+assertThrows(
+"Single string value should throw an exception",
+SolrException.class,
+() -> {
+ toTestByteEncoding.getVectorBuilder("string").getByteVector();
+});
+MatcherAssert.assertThat(
+thrown.getMessage(),
+is(
+"incorrect vector format. The expected format is:'[fb,b2..b3]'
where each element b is a byte (-128 to 127)"));
Review Comment:
same as above, I suspect there's a typo in the log message
--
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] alessandrobenedetti commented on a diff in pull request #1435: SOLR-16674: Introduce dense vector byte encoding
alessandrobenedetti commented on code in PR #1435:
URL: https://github.com/apache/solr/pull/1435#discussion_r1154177094
##
solr/core/src/java/org/apache/solr/schema/DenseVectorField.java:
##
@@ -205,53 +257,144 @@ public IndexableField createField(SchemaField field,
Object parsedVector) {
* org.apache.solr.handler.loader.CSVLoader} produces an ArrayList of String
- {@link
* org.apache.solr.handler.loader.JsonLoader} produces an ArrayList of
Double - {@link
* org.apache.solr.handler.loader.JavabinLoader} produces an ArrayList of
Float
- *
- * @param inputValue - An {@link ArrayList} containing the elements of the
vector
- * @return the vector parsed
*/
- float[] parseVector(Object inputValue) {
-if (!(inputValue instanceof List)) {
- throw new SolrException(
- SolrException.ErrorCode.BAD_REQUEST,
- "incorrect vector format."
- + " The expected format is an array :'[f1,f2..f3]' where each
element f is a float");
+ public VectorBuilder getVectorBuilder(Object inputValue) {
+switch (vectorEncoding) {
+ case FLOAT32:
+return new VectorBuilder.Float32VectorBuilder(dimension, inputValue);
+ case BYTE:
+return new VectorBuilder.ByteVectorBuilder(dimension, inputValue);
+ default:
+throw new SolrException(
+SolrException.ErrorCode.SERVER_ERROR,
+"Unexpected state. Vector Encoding: " + vectorEncoding);
}
-List inputVector = (List) inputValue;
-if (inputVector.size() != dimension) {
- throw new SolrException(
- SolrException.ErrorCode.BAD_REQUEST,
- "incorrect vector dimension."
- + " The vector value has size "
- + inputVector.size()
- + " while it is expected a vector with size "
- + dimension);
+ }
+
+ abstract static class VectorBuilder {
+
+protected int dimension;
+protected Object inputValue;
+
+public float[] getFloatVector() {
+ throw new RuntimeException("Not implemented");
}
-float[] vector = new float[dimension];
-if (inputVector.get(0) instanceof CharSequence) {
- for (int i = 0; i < dimension; i++) {
-try {
- vector[i] = Float.parseFloat(inputVector.get(i).toString());
-} catch (NumberFormatException e) {
- throw new SolrException(
- SolrException.ErrorCode.BAD_REQUEST,
- "incorrect vector element: '"
- + inputVector.get(i)
- + "'. The expected format is:'[f1,f2..f3]' where each
element f is a float");
+protected BytesRef getByteVector() {
+ throw new RuntimeException("Not implemented");
+}
+
+protected void parseVector() {
+ if (!(inputValue instanceof List)) {
+throw new SolrException(
+SolrException.ErrorCode.BAD_REQUEST, "incorrect vector format. " +
errorMessage());
+ }
+ List inputVector = (List) inputValue;
+ if (inputVector.size() != dimension) {
+throw new SolrException(
+SolrException.ErrorCode.BAD_REQUEST,
+"incorrect vector dimension."
++ " The vector value has size "
++ inputVector.size()
++ " while it is expected a vector with size "
++ dimension);
+ }
+
+ if (inputVector.get(0) instanceof CharSequence) {
+for (int i = 0; i < dimension; i++) {
+ try {
+addStringElement(inputVector.get(i).toString());
+ } catch (NumberFormatException e) {
+throw new SolrException(
+SolrException.ErrorCode.BAD_REQUEST,
+"incorrect vector element: '" + inputVector.get(i) + "'. " +
errorMessage());
+ }
}
+ } else if (inputVector.get(0) instanceof Number) {
+for (int i = 0; i < dimension; i++) {
+ addNumberElement((Number) inputVector.get(i));
+}
+ } else {
+throw new SolrException(
+SolrException.ErrorCode.BAD_REQUEST, "incorrect vector format. " +
errorMessage());
}
-} else if (inputVector.get(0) instanceof Number) {
- for (int i = 0; i < dimension; i++) {
-vector[i] = ((Number) inputVector.get(i)).floatValue();
+}
+
+protected abstract void addNumberElement(Number element);
+
+protected abstract void addStringElement(String element);
+
+protected abstract String errorMessage();
+
+static class ByteVectorBuilder extends VectorBuilder {
+ private BytesRefBuilder byteRefBuilder;
+ private BytesRef byteVector;
+
+ public ByteVectorBuilder(int dimension, Object inputValue) {
+this.dimension = dimension;
+this.inputValue = inputValue;
+ }
+
+ @Override
+ public BytesRef getByteVector() {
+if (byteVector == null) {
+ byteRefBuilder = new BytesRefBuilder();
+ parseVector();
+ byteVector = byteRefBuilder.toB
[GitHub] [solr] alessandrobenedetti commented on a diff in pull request #1435: SOLR-16674: Introduce dense vector byte encoding
alessandrobenedetti commented on code in PR #1435:
URL: https://github.com/apache/solr/pull/1435#discussion_r1154173619
##
solr/core/src/java/org/apache/solr/schema/DenseVectorField.java:
##
@@ -205,53 +257,144 @@ public IndexableField createField(SchemaField field,
Object parsedVector) {
* org.apache.solr.handler.loader.CSVLoader} produces an ArrayList of String
- {@link
* org.apache.solr.handler.loader.JsonLoader} produces an ArrayList of
Double - {@link
* org.apache.solr.handler.loader.JavabinLoader} produces an ArrayList of
Float
- *
- * @param inputValue - An {@link ArrayList} containing the elements of the
vector
- * @return the vector parsed
*/
- float[] parseVector(Object inputValue) {
-if (!(inputValue instanceof List)) {
- throw new SolrException(
- SolrException.ErrorCode.BAD_REQUEST,
- "incorrect vector format."
- + " The expected format is an array :'[f1,f2..f3]' where each
element f is a float");
+ public VectorBuilder getVectorBuilder(Object inputValue) {
+switch (vectorEncoding) {
+ case FLOAT32:
+return new VectorBuilder.Float32VectorBuilder(dimension, inputValue);
+ case BYTE:
+return new VectorBuilder.ByteVectorBuilder(dimension, inputValue);
+ default:
+throw new SolrException(
+SolrException.ErrorCode.SERVER_ERROR,
+"Unexpected state. Vector Encoding: " + vectorEncoding);
}
-List inputVector = (List) inputValue;
-if (inputVector.size() != dimension) {
- throw new SolrException(
- SolrException.ErrorCode.BAD_REQUEST,
- "incorrect vector dimension."
- + " The vector value has size "
- + inputVector.size()
- + " while it is expected a vector with size "
- + dimension);
+ }
+
+ abstract static class VectorBuilder {
+
+protected int dimension;
+protected Object inputValue;
+
+public float[] getFloatVector() {
+ throw new RuntimeException("Not implemented");
Review Comment:
check if "throw new UnsupportedOperationException" is 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
