[jira] [Commented] (SOLR-14688) First party package implementation design
[ https://issues.apache.org/jira/browse/SOLR-14688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17166936#comment-17166936 ] Ishan Chattopadhyaya commented on SOLR-14688: - bq. migrating some of our existing code to first party packages sounds like big deal to me. +1, totally agree. This is a huge deal. bq. Wouldn't a SIP be a better fit for this? I think SIP process is too slow (or doesn't work), and we want to move fast with this initiative (ideally, prepare the ground work for having first party packages by the next release 8.7). As per our discussions, David, we reached consensus. Also, Jan is on board. If all of us in the community is on board with the overall design, we can start fleshing out the lower level details and then possibly some prototype. > First party package implementation design > - > > Key: SOLR-14688 > URL: https://issues.apache.org/jira/browse/SOLR-14688 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > > Here's the design document for first party packages: > https://docs.google.com/document/d/1n7gB2JAdZhlJKFrCd4Txcw4HDkdk7hlULyAZBS-wXrE/edit?usp=sharing -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dweiss commented on pull request #1700: Found that asciidoctor 1.5.6.2 cause build-site to fail on long anchors
dweiss commented on pull request #1700: URL: https://github.com/apache/lucene-solr/pull/1700#issuecomment-664811167 Please use gradle to compile the refguide. It'll keep dependencies up to date and consistent. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
murblanc commented on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664608589 EagerlyFetchedSolrCluster would then guarantee immutability? Must also be careful not too fetch too much. Autoscaling for example might not always need all details on everything. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley merged pull request #1672: SOLR-14651: Metrics History could disable better
dsmiley merged pull request #1672: URL: https://github.com/apache/lucene-solr/pull/1672 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy opened a new pull request #1701: SOLR-14671: Parsing dynamic ZK config sometimes cause NuberFormatException
janhoy opened a new pull request #1701: URL: https://github.com/apache/lucene-solr/pull/1701 See https://issues.apache.org/jira/browse/SOLR-14671 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] HoustonPutman commented on a change in pull request #1701: SOLR-14671: Parsing dynamic ZK config sometimes cause NuberFormatException
HoustonPutman commented on a change in pull request #1701: URL: https://github.com/apache/lucene-solr/pull/1701#discussion_r461777172 ## File path: solr/core/src/java/org/apache/solr/handler/admin/ZookeeperStatusHandler.java ## @@ -112,15 +112,21 @@ public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse rsp) throw .map(h -> h.resolveClientPortAddress() + ":" + h.clientPort) .sorted().collect(Collectors.toList()); List dynamicHosts = zkDynamicConfig.getServers().stream() - .map(h -> h.resolveClientPortAddress() + ":" + h.clientPort) + .map(h -> h.resolveClientPortAddress() + ":" + (h.clientPort != null ? h.clientPort : "2181")) Review comment: Maybe instead of defaulting to `2181`, we default to `hostsFromConnectionString.getServers().get(0).clientPort`? I imagine that would match a vast majority of scenarios. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] HoustonPutman commented on pull request #1704: Found that asciidoctor 1.5.6.2 cause build-site to fail on long anchors (#1700)
HoustonPutman commented on pull request #1704: URL: https://github.com/apache/lucene-solr/pull/1704#issuecomment-665290044 Looks good to me! 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on a change in pull request #1701: SOLR-14671: Parsing dynamic ZK config sometimes cause NuberFormatException
janhoy commented on a change in pull request #1701: URL: https://github.com/apache/lucene-solr/pull/1701#discussion_r461461015 ## File path: solr/core/src/java/org/apache/solr/handler/admin/ZookeeperStatusHandler.java ## @@ -112,15 +112,21 @@ public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse rsp) throw .map(h -> h.resolveClientPortAddress() + ":" + h.clientPort) .sorted().collect(Collectors.toList()); List dynamicHosts = zkDynamicConfig.getServers().stream() - .map(h -> h.resolveClientPortAddress() + ":" + h.clientPort) + .map(h -> h.resolveClientPortAddress() + ":" + (h.clientPort != null ? h.clientPort : "2181")) Review comment: This is not bullet proof if e.g. user has `clientPort=1234` in `zoo.cfg` and in zkHost connection string. Then we'll add a warning that dynamic config differs from zkHost, which is not entirely true since we just lack the port part. We have no way from client to read the `clientPort` from server except from connecting to the server with 4LW *ont the clientPort* which is a chicken and egg. This hack will make the comparison work for default port, which is a compromise. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1702: SOLR-14681
MarcusSorealheis commented on pull request #1702: URL: https://github.com/apache/lucene-solr/pull/1702#issuecomment-664779946 @noblepaul @chatman other package masters 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on pull request #1701: SOLR-14671: Parsing dynamic ZK config sometimes cause NuberFormatException
janhoy commented on pull request #1701: URL: https://github.com/apache/lucene-solr/pull/1701#issuecomment-664940160 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta merged pull request #1695: LUCENE-9321: Fix Javadoc offline link base url for snapshot build
mocobeta merged pull request #1695: URL: https://github.com/apache/lucene-solr/pull/1695 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf merged pull request #1698: SOLR-13169 Improve docs for MOVEREPLICA
gus-asf merged pull request #1698: URL: https://github.com/apache/lucene-solr/pull/1698 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf opened a new pull request #1700: Found that asciidoctor 1.5.6.2 cause build-site to fail on long anchors
gus-asf opened a new pull request #1700: URL: https://github.com/apache/lucene-solr/pull/1700 Documenting need to have ascii doctor version up to date. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] MarcusSorealheis opened a new pull request #1702: SOLR-14681
MarcusSorealheis opened a new pull request #1702: URL: https://github.com/apache/lucene-solr/pull/1702 # Description Add the ability to delete a locally stored a distributed jar # Solution PR # Tests I add test for changes to the package stores. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `master` branch. - [ ] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman commented on pull request #1702: SOLR-14681
chatman commented on pull request #1702: URL: https://github.com/apache/lucene-solr/pull/1702#issuecomment-664784298 Thanks for working on this. Unfortunately, I'm a bit busy this week and may be able to get to this by end of week. But if someone else can please review this meanwhile, please don't wait for me. @noblepaul 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf opened a new pull request #1698: SOLR-13169 Improve docs for MOVEREPLICA
gus-asf opened a new pull request #1698: URL: https://github.com/apache/lucene-solr/pull/1698 - document additional existing parameters, second pass fixing spelling and other details. (cherry picked from commit b00d747eb6a94ab5775258b032e621f998ec44ba) SOLR-13169 Improve docs for MOVEREPLICA - better parity with ref guide for v2 api descriptions (cherry picked from commit 396490b65ca1af6ff1f1157a9896c9528c234eea) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta edited a comment on pull request #1695: LUCENE-9321: Fix Javadoc offline link base url for snapshot build
mocobeta edited a comment on pull request #1695: URL: https://github.com/apache/lucene-solr/pull/1695#issuecomment-665018578 Thanks for confirming, I merged it. p.s. > I don't fully understand the issue, but as a workaround it's ok for now. Here is a bit more detailed explanation for the second change I omitted for laziness Without the change, several invalid links are generated (in solr-test-framework javadocs). e.g.: ``` BROKEN LINK: file:///mnt/hdd/repo/lucene-solr/lucene/build/documentation/core/org/apache/lucene/util/LuceneTestCase.html BROKEN LINK: file:///mnt/hdd/repo/lucene-solr/solr/build/documentation/solrj/org/apache/solr/client/solrj/embedded/JettySolrRunner.html ``` They are invalid because `LuceneTestCase` actually belongs to `lucene-test-framework` module, and `JettySolrRunner` belongs to `solr-core` module. Seems like javadoc tool sees only package names in `element-list` and don't check if the classes really exist in the package when making links to referred classes (maybe it's an expected behaviour since the tool cannot retrieve the actual HTML files when `--linkoffline` option is used). (Of course if we have no shared package names between modules, this problem should not occur.) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley closed pull request #289: SOLR-11745: change logging references to getName
dsmiley closed pull request #289: URL: https://github.com/apache/lucene-solr/pull/289 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] sigram commented on a change in pull request #1672: SOLR-14651: Metrics History could disable better
sigram commented on a change in pull request #1672:
URL: https://github.com/apache/lucene-solr/pull/1672#discussion_r461682200
##
File path: solr/solrj/src/java/org/apache/solr/common/util/ExecutorUtil.java
##
@@ -77,6 +77,12 @@ public static void
shutdownAndAwaitTermination(ExecutorService pool) {
awaitTermination(pool);
}
+ public static void shutdownNowAndAwaitTermination(ExecutorService pool) {
+if(pool == null) return;
Review comment:
missing space after `if`
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley opened a new pull request #1703: SOLR-14686: remove SolrCore.logid
dsmiley opened a new pull request #1703: URL: https://github.com/apache/lucene-solr/pull/1703 Obsoleted by MDC https://issues.apache.org/jira/browse/SOLR-14686 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1703: SOLR-14686: remove SolrCore.logid
dsmiley commented on a change in pull request #1703:
URL: https://github.com/apache/lucene-solr/pull/1703#discussion_r461837562
##
File path: solr/core/src/java/org/apache/solr/core/SolrCore.java
##
@@ -922,20 +920,15 @@ private UpdateHandler createUpdateHandler(String
className, UpdateHandler update
return createReloadedUpdateHandler(className, "Update Handler",
updateHandler);
}
- public SolrCore(CoreContainer coreContainer, CoreDescriptor cd, ConfigSet
configSet) {
-this(coreContainer, cd, configSet, null,
-null, null, null, false);
- }
-
public CoreContainer getCoreContainer() {
return coreContainer;
}
+ SolrCore(CoreContainer coreContainer, CoreDescriptor cd, ConfigSet
configSet) {
Review comment:
I just co-located the constructors together, and furthermore reduced the
access scope. I could have left this out. The former javadocs were obsoleted
recently.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf commented on pull request #1700: Found that asciidoctor 1.5.6.2 cause build-site to fail on long anchors
gus-asf commented on pull request #1700: URL: https://github.com/apache/lucene-solr/pull/1700#issuecomment-665110670 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf merged pull request #1700: Found that asciidoctor 1.5.6.2 cause build-site to fail on long anchors
gus-asf merged pull request #1700: URL: https://github.com/apache/lucene-solr/pull/1700 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman commented on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
chatman commented on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664610279 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf opened a new pull request #1699: SOLR-13169 Improve docs for MOVEREPLICA
gus-asf opened a new pull request #1699: URL: https://github.com/apache/lucene-solr/pull/1699 - document additional existing parameters, second pass fixing spelling and other details. (cherry picked from commit b00d747eb6a94ab5775258b032e621f998ec44ba) SOLR-13169 Improve docs for MOVEREPLICA - better parity with ref guide for v2 api descriptions (cherry picked from commit 396490b65ca1af6ff1f1157a9896c9528c234eea) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf merged pull request #1699: SOLR-13169 Improve docs for MOVEREPLICA
gus-asf merged pull request #1699: URL: https://github.com/apache/lucene-solr/pull/1699 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ctargett commented on pull request #1700: Found that asciidoctor 1.5.6.2 cause build-site to fail on long anchors
ctargett commented on pull request #1700: URL: https://github.com/apache/lucene-solr/pull/1700#issuecomment-66472 This is only a problem if you already had it installed before it was upgraded several months ago. At that time, I sent mail to the Dev list explaining the need for people to specifically upgrade, and it’s explained in the Jira issue I used at that time. I’m on vacation, so I’ll leave searching for those things up to you. For people who never installed any of the dependencies, I believe the right version of the gem gets installed with jekyll-asciidoc gem, it just doesn’t upgrade it if you already have it, which is why I’d removed it from the README. And as soon as we move to Gradle, the need for any dependencies goes away entirely. So what you choose to do with this PR with all that info is up to you, but I’d prefer it be clear and accurate about who needs the extra step. As I mentioned, I’m on vacation, so won’t be reviewing this again until next week at the earliest. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] henrik242 commented on pull request #1701: SOLR-14671: Parsing dynamic ZK config sometimes cause NuberFormatException
henrik242 commented on pull request #1701: URL: https://github.com/apache/lucene-solr/pull/1701#issuecomment-664775724 By the way, should the rest of the integer parsers (leaderPort etc) have similar null safety checks? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14671) NumberFormatException on ZK Status page when client port missing in dynamic config
[
https://issues.apache.org/jira/browse/SOLR-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved SOLR-14671.
Resolution: Fixed
> NumberFormatException on ZK Status page when client port missing in dynamic
> config
> --
>
> Key: SOLR-14671
> URL: https://issues.apache.org/jira/browse/SOLR-14671
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, SolrCloud
>Affects Versions: 8.6
>Reporter: Henrik
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The Admin -> Cloud -> ZK Status page in Solr 8.6.0 does not show any data
> except for the error message "null". I get the following exception in
> solr.log:
> {code:java}
> ERROR [20200721T081301,835] qtp478489615-21
> org.apache.solr.handler.RequestHandlerBase - java.lang.NumberFormatException:
> null
> at java.base/java.lang.Integer.parseInt(Integer.java:620)
> at java.base/java.lang.Integer.parseInt(Integer.java:776)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig$Server.parseLine(ZkDynamicConfig.java:142)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.lambda$parseLines$0(ZkDynamicConfig.java:58)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.parseLines(ZkDynamicConfig.java:53)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at
> org.eclipse.jetty.io.Chann
[GitHub] [lucene-solr] mocobeta commented on pull request #1695: LUCENE-9321: Fix Javadoc offline link base url for snapshot build
mocobeta commented on pull request #1695: URL: https://github.com/apache/lucene-solr/pull/1695#issuecomment-665018578 Thanks for confirming, I merged it. p.s. > I don't fully understand the issue, but as a workaround it's ok for now. Here is a bit more detailed explanation for the second change I omitted for laziness... Without the change, several invalid links are generated (in solr-test-framework javadocs). e.g.: ``` BROKEN LINK: file:///mnt/hdd/repo/lucene-solr/lucene/build/documentation/core/org/apache/lucene/util/LuceneTestCase.html BROKEN LINK: file:///mnt/hdd/repo/lucene-solr/solr/build/documentation/solrj/org/apache/solr/client/solrj/embedded/JettySolrRunner.html ``` They are invalid because `LuceneTestCase` actually belongs to `lucene-test-framework` module, and `JettySolrRunner` belongs to `solr-core` module. Seems like javadoc tool sees only package names in `element-list` and don't check if the classes really exist in the package when making links to referred classes (maybe it's an expected behaviour since the tool cannot retrieve the actual HTML files when `--linkoffline` option is used). (Of course if we have no shared package names between modules, this problem should not occur.) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14671) NumberFormatException on ZK Status page when client port missing in dynamic config
[
https://issues.apache.org/jira/browse/SOLR-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167053#comment-17167053
]
ASF subversion and git services commented on SOLR-14671:
Commit ebb5219b1b7d7baba9af6653f946cc1c66b40a93 in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ebb5219 ]
SOLR-14671: Parsing dynamic ZK config sometimes cause NuberFormatException
(#1701)
> NumberFormatException on ZK Status page when client port missing in dynamic
> config
> --
>
> Key: SOLR-14671
> URL: https://issues.apache.org/jira/browse/SOLR-14671
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, SolrCloud
>Affects Versions: 8.6
>Reporter: Henrik
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The Admin -> Cloud -> ZK Status page in Solr 8.6.0 does not show any data
> except for the error message "null". I get the following exception in
> solr.log:
> {code:java}
> ERROR [20200721T081301,835] qtp478489615-21
> org.apache.solr.handler.RequestHandlerBase - java.lang.NumberFormatException:
> null
> at java.base/java.lang.Integer.parseInt(Integer.java:620)
> at java.base/java.lang.Integer.parseInt(Integer.java:776)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig$Server.parseLine(ZkDynamicConfig.java:142)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.lambda$parseLines$0(ZkDynamicConfig.java:58)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.parseLines(ZkDynamicConfig.java:53)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpCh
[GitHub] [lucene-solr] noblepaul edited a comment on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
noblepaul edited a comment on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664402636 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf opened a new pull request #1704: Found that asciidoctor 1.5.6.2 cause build-site to fail on long anchors (#1700)
gus-asf opened a new pull request #1704: URL: https://github.com/apache/lucene-solr/pull/1704 * Found that asciidoctor 1.5.6.2 cause build-site to fail on long anchors, 2.0.10 definitely works. * Clarity on when an upgrade is required, also fix obsolete wording from when PDFs were generated. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14671) NumberFormatException on ZK Status page when client port missing in dynamic config
[
https://issues.apache.org/jira/browse/SOLR-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167069#comment-17167069
]
ASF subversion and git services commented on SOLR-14671:
Commit 8fdf54a746afdfba8c640fc2db14ca4c9cd13556 in lucene-solr's branch
refs/heads/branch_8_6 from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8fdf54a ]
SOLR-14671: Parsing dynamic ZK config sometimes cause NuberFormatException
(#1701)
(cherry picked from commit ebb5219b1b7d7baba9af6653f946cc1c66b40a93)
> NumberFormatException on ZK Status page when client port missing in dynamic
> config
> --
>
> Key: SOLR-14671
> URL: https://issues.apache.org/jira/browse/SOLR-14671
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, SolrCloud
>Affects Versions: 8.6
>Reporter: Henrik
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The Admin -> Cloud -> ZK Status page in Solr 8.6.0 does not show any data
> except for the error message "null". I get the following exception in
> solr.log:
> {code:java}
> ERROR [20200721T081301,835] qtp478489615-21
> org.apache.solr.handler.RequestHandlerBase - java.lang.NumberFormatException:
> null
> at java.base/java.lang.Integer.parseInt(Integer.java:620)
> at java.base/java.lang.Integer.parseInt(Integer.java:776)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig$Server.parseLine(ZkDynamicConfig.java:142)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.lambda$parseLines$0(ZkDynamicConfig.java:58)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.parseLines(ZkDynamicConfig.java:53)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.
[jira] [Commented] (SOLR-11611) Starting Solr using solr.cmd fails under Windows, when the path contains a space
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167082#comment-17167082
]
Jan Høydahl commented on SOLR-11611:
Here's Uwe's comment from the 8.5 VOTE thread:
{quote} - Solr starts and stops perfectly on Windows with whitespace in path
name: Java 8, Java 11 and Java 14 (coming out soon){quote}
I think you might be right that the {{(x86)}} part of the path name might be
what the patch tries to address, but let's push this to 8.7 and do some more
validation. The double (5 ^'s) escaping and then unescaping part seems scary as
well, but it should be possible to validate with some set of test paths.. Don't
you just love Windows batch scripting? One day I might start a VOTE thread to
discontinue official Windows support for Solr. :)
> Starting Solr using solr.cmd fails under Windows, when the path contains a
> space
>
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Components: SolrCLI
>Affects Versions: 7.1, 7.4
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
>Priority: Blocker
> Fix For: 8.7
>
> Attachments: SOLR-11611.patch, SOLR-11611.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {quote}C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14671) NumberFormatException on ZK Status page when client port missing in dynamic config
[
https://issues.apache.org/jira/browse/SOLR-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167065#comment-17167065
]
ASF subversion and git services commented on SOLR-14671:
Commit 993b09c3be11942cbe3bd468936711c8c23d7daa in lucene-solr's branch
refs/heads/branch_8x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=993b09c ]
SOLR-14671: Parsing dynamic ZK config sometimes cause NuberFormatException
(#1701)
(cherry picked from commit ebb5219b1b7d7baba9af6653f946cc1c66b40a93)
> NumberFormatException on ZK Status page when client port missing in dynamic
> config
> --
>
> Key: SOLR-14671
> URL: https://issues.apache.org/jira/browse/SOLR-14671
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, SolrCloud
>Affects Versions: 8.6
>Reporter: Henrik
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The Admin -> Cloud -> ZK Status page in Solr 8.6.0 does not show any data
> except for the error message "null". I get the following exception in
> solr.log:
> {code:java}
> ERROR [20200721T081301,835] qtp478489615-21
> org.apache.solr.handler.RequestHandlerBase - java.lang.NumberFormatException:
> null
> at java.base/java.lang.Integer.parseInt(Integer.java:620)
> at java.base/java.lang.Integer.parseInt(Integer.java:776)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig$Server.parseLine(ZkDynamicConfig.java:142)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.lambda$parseLines$0(ZkDynamicConfig.java:58)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.parseLines(ZkDynamicConfig.java:53)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.j
[jira] [Updated] (SOLR-11611) Starting Solr using solr.cmd fails under Windows, when the path contains a parenthesis character
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Furrer updated SOLR-11611:
Summary: Starting Solr using solr.cmd fails under Windows, when the path
contains a parenthesis character (was: Starting Solr using solr.cmd fails
under Windows, when the path contains a parenthesis charactercharacter)
> Starting Solr using solr.cmd fails under Windows, when the path contains a
> parenthesis character
>
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Components: SolrCLI
>Affects Versions: 7.1, 7.4
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
>Priority: Blocker
> Fix For: 8.7
>
> Attachments: SOLR-11611.patch, SOLR-11611.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {quote}C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-11611) Starting Solr using solr.cmd fails under Windows, when the path contains a parenthesis charactercharacter
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Furrer updated SOLR-11611:
Summary: Starting Solr using solr.cmd fails under Windows, when the path
contains a parenthesis charactercharacter (was: Starting Solr using solr.cmd
fails under Windows, when the path contains a space)
> Starting Solr using solr.cmd fails under Windows, when the path contains a
> parenthesis charactercharacter
> -
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Components: SolrCLI
>Affects Versions: 7.1, 7.4
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
>Priority: Blocker
> Fix For: 8.7
>
> Attachments: SOLR-11611.patch, SOLR-11611.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {quote}C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-11611) Starting Solr using solr.cmd fails under Windows, when the path contains a parenthesis character
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167100#comment-17167100
]
Jakob Furrer commented on SOLR-11611:
-
Jira title changed to "Starting Solr using solr.cmd fails under Windows, when
the path contains a parenthesis character".
> Starting Solr using solr.cmd fails under Windows, when the path contains a
> parenthesis character
>
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Components: SolrCLI
>Affects Versions: 7.1, 7.4
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
>Priority: Blocker
> Fix For: 8.7
>
> Attachments: SOLR-11611.patch, SOLR-11611.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {quote}C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14690) increased minExactCount related cache use
Christine Poerschke created SOLR-14690:
--
Summary: increased minExactCount related cache use
Key: SOLR-14690
URL: https://issues.apache.org/jira/browse/SOLR-14690
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
SOLR-13289 added
[https://lucene.apache.org/solr/guide/8_6/common-query-parameters.html#minexactcount-parameter]
support.
Currently queries using the same {{minExactCount}} parameter value can hit the
cache (assuming the non-{{minExactCount}} parameters match).
It might be useful to increase cache hits beyond {{minExactCount}} same-ness
e.g.
* a {{minExactCount=100}} query being able to use a {{minExactCount=1000}}
cache entry, and/or
* a query with a {{minExactCount}} restriction being able to use a cache entry
from a query without the restriction.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13289) Support for BlockMax WAND
[ https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167124#comment-17167124 ] Christine Poerschke commented on SOLR-13289: "increased minExactCount related cache use" ticket created: SOLR-14690 > Support for BlockMax WAND > - > > Key: SOLR-13289 > URL: https://issues.apache.org/jira/browse/SOLR-13289 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Fix For: master (9.0), 8.6 > > Attachments: SOLR-13289.patch, SOLR-13289.patch > > Time Spent: 5.5h > Remaining Estimate: 0h > > LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to > expose this via Solr. When enabled, the numFound returned will not be exact. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14489) ReplicationHandler: remove deprecated "master.commitReserveDuration" use (in favour "commitReserveDuration")
[
https://issues.apache.org/jira/browse/SOLR-14489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167125#comment-17167125
]
ASF subversion and git services commented on SOLR-14489:
Commit 2f155aa0c3712127c54369b49ae834afb9511de4 in lucene-solr's branch
refs/heads/master from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2f155aa ]
SOLR-14489: remove ReplicationHandler's deprecated
"master.commitReserveDuration" use (in favour of "commitReserveDuration")
> ReplicationHandler: remove deprecated "master.commitReserveDuration" use (in
> favour "commitReserveDuration")
>
>
> Key: SOLR-14489
> URL: https://issues.apache.org/jira/browse/SOLR-14489
> Project: Solr
> Issue Type: Task
> Components: replication (java)
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-14489.patch
>
>
> SOLR-10962 in Solr 7.1 deprecated the ReplicationHandler's
> {{master.commitReserveDuration}} sub-element in favour of a direct
> {{commitReserveDuration}} element for use in all modes:
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.1.0/solr/CHANGES.txt#L60-L61
> This ticket here is to remove use of the deprecated sub-element from Solr 8.6
> onwards.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14489) ReplicationHandler: remove deprecated "master.commitReserveDuration" use (in favour "commitReserveDuration")
[
https://issues.apache.org/jira/browse/SOLR-14489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-14489:
---
Fix Version/s: master (9.0)
Resolution: Fixed
Status: Resolved (was: Patch Available)
> ReplicationHandler: remove deprecated "master.commitReserveDuration" use (in
> favour "commitReserveDuration")
>
>
> Key: SOLR-14489
> URL: https://issues.apache.org/jira/browse/SOLR-14489
> Project: Solr
> Issue Type: Task
> Components: replication (java)
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: SOLR-14489.patch
>
>
> SOLR-10962 in Solr 7.1 deprecated the ReplicationHandler's
> {{master.commitReserveDuration}} sub-element in favour of a direct
> {{commitReserveDuration}} element for use in all modes:
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.1.0/solr/CHANGES.txt#L60-L61]
> This ticket here is to remove use of the deprecated sub-element from Solr 9.0
> onwards.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14489) ReplicationHandler: remove deprecated "master.commitReserveDuration" use (in favour "commitReserveDuration")
[
https://issues.apache.org/jira/browse/SOLR-14489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-14489:
---
Description:
SOLR-10962 in Solr 7.1 deprecated the ReplicationHandler's
{{master.commitReserveDuration}} sub-element in favour of a direct
{{commitReserveDuration}} element for use in all modes:
[https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.1.0/solr/CHANGES.txt#L60-L61]
This ticket here is to remove use of the deprecated sub-element from Solr 9.0
onwards.
was:
SOLR-10962 in Solr 7.1 deprecated the ReplicationHandler's
{{master.commitReserveDuration}} sub-element in favour of a direct
{{commitReserveDuration}} element for use in all modes:
https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.1.0/solr/CHANGES.txt#L60-L61
This ticket here is to remove use of the deprecated sub-element from Solr 8.6
onwards.
> ReplicationHandler: remove deprecated "master.commitReserveDuration" use (in
> favour "commitReserveDuration")
>
>
> Key: SOLR-14489
> URL: https://issues.apache.org/jira/browse/SOLR-14489
> Project: Solr
> Issue Type: Task
> Components: replication (java)
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-14489.patch
>
>
> SOLR-10962 in Solr 7.1 deprecated the ReplicationHandler's
> {{master.commitReserveDuration}} sub-element in favour of a direct
> {{commitReserveDuration}} element for use in all modes:
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.1.0/solr/CHANGES.txt#L60-L61]
> This ticket here is to remove use of the deprecated sub-element from Solr 9.0
> onwards.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14489) ReplicationHandler: remove deprecated "master.commitReserveDuration" use (in favour "commitReserveDuration")
[
https://issues.apache.org/jira/browse/SOLR-14489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167129#comment-17167129
]
Christine Poerschke commented on SOLR-14489:
On branch_8x e.g.
[https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.0/solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java#L1362]
the deprecated use is already subject to a Version.LUCENE_7_1_0 check. So for
clarity I'll leave that in place and unchanged and only from 9.0 onwards the
deprecated use will be fully gone away.
> ReplicationHandler: remove deprecated "master.commitReserveDuration" use (in
> favour "commitReserveDuration")
>
>
> Key: SOLR-14489
> URL: https://issues.apache.org/jira/browse/SOLR-14489
> Project: Solr
> Issue Type: Task
> Components: replication (java)
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-14489.patch
>
>
> SOLR-10962 in Solr 7.1 deprecated the ReplicationHandler's
> {{master.commitReserveDuration}} sub-element in favour of a direct
> {{commitReserveDuration}} element for use in all modes:
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.1.0/solr/CHANGES.txt#L60-L61
> This ticket here is to remove use of the deprecated sub-element from Solr 8.6
> onwards.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14673) Add CLI for Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167130#comment-17167130
]
Andrzej Bialecki commented on SOLR-14673:
-
[~jbernste] minor nit on the naming: widely accepted abbreviations for
"standard input" and "standard output" are {{stdin}} and {{stdout}} (without
the middle 'n'). Using these names would be more user friendly.
> Add CLI for Streaming Expressions
> -
>
> Key: SOLR-14673
> URL: https://issues.apache.org/jira/browse/SOLR-14673
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: SOLR-14673.patch, SOLR-14673.patch, SOLR-14673.patch,
> SOLR-14673.patch, SOLR-14673.patch
>
>
> This ticket will provide a simple CLI that will run a Streaming Expression
> from the command line and return the results as a delimited result set. This
> will allow Streaming Expressions to be used from the command line to extract
> data as well as load data into Solr.
> Sample syntax:
> {code:java}
> bin/expr expr_file{code}
> This will run the expression in _expr_file_.
> Output will be to standard out as delimited records.
> *Standard-In, Standard-out and Pipe Composition.*
> The CLI can read from *standard-in* and write to *standard-out* in delimited
> records. This allows Streaming Expressions to be composed using unix pipes
> with other command line tools and other streaming expressions. Example syntax:
> {code:java}
> cat data.csv | ./bin/expr load.expr {code}
> The load.expr file uses the *stndin()* function to read from standard-in and
> load date to Solr. Here is a sample load.expr
> {code:java}
> let(cli-zkhost="localhost:9983",
>
> update(collection1,
>parseCSV(stndin()))
> {code}
> In the example above the *let* expression is used to set the *cli-zkhost* and
> then run the Streaming Expression:
> {code:java}
> update(collection1,
>parseCSV(stndin()){code}
> The *stndin* function reads the data from standard-in. The *parseCSV*
> function parses the lines into tuples and the *update* function sends the
> data to collection1 for indexing.
>
> *Querying Solr and Pipe Composition*
> The CLI can also be used to query Solr and pipe the result to other
> applications on the command line. This can automate activities like alerting,
> data backup, replication etc...
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-11611) Starting Solr using solr.cmd fails under Windows, when the path contains a parenthesis character
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-11611:
---
Component/s: scripts and tools
> Starting Solr using solr.cmd fails under Windows, when the path contains a
> parenthesis character
>
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Components: scripts and tools, SolrCLI
>Affects Versions: 7.1, 7.4
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
>Priority: Blocker
> Fix For: 8.7
>
> Attachments: SOLR-11611.patch, SOLR-11611.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {quote}C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14684) CloudExitableDirectoryReaderTest failing about 25% of the time
[ https://issues.apache.org/jira/browse/SOLR-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167134#comment-17167134 ] Erick Erickson commented on SOLR-14684: --- I can get this to fail pretty quickly, so let me know if you have anything you want me to test. Or, for that matter, if you have anything you want me to run to get information. > CloudExitableDirectoryReaderTest failing about 25% of the time > -- > > Key: SOLR-14684 > URL: https://issues.apache.org/jira/browse/SOLR-14684 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Affects Versions: master (9.0) >Reporter: Erick Erickson >Priority: Major > Attachments: stdout > > > If I beast this on my local machine, it fails (non reproducibly of course) > about 1/4 of the time. Log attached. The test itself hasn't changed in 11 > months or so. > It looks like occasionally the calls throw an error rather than return > partial results with a message: "Time allowed to handle this request > exceeded:[]". > It's been failing very intermittently for a couple of years, but the failure > rate really picked up in the last couple of weeks. IDK whether the failures > prior to the last couple of weeks are the same root cause. > I'll do some spelunking to see if I can pinpoint the commit that made this > happen, but it'll take a while. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14608) Faster sorting for the /export handler
[ https://issues.apache.org/jira/browse/SOLR-14608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167139#comment-17167139 ] ASF subversion and git services commented on SOLR-14608: Commit 536d962d6e016573cafd2f420511e4f7083e0468 in lucene-solr's branch refs/heads/jira/SOLR-14608-export from Andrzej Bialecki [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=536d962 ] SOLR-14608: Fix generics / raw types, move around the timer metrics so that they make sense. > Faster sorting for the /export handler > -- > > Key: SOLR-14608 > URL: https://issues.apache.org/jira/browse/SOLR-14608 > Project: Solr > Issue Type: New Feature >Reporter: Joel Bernstein >Assignee: Andrzej Bialecki >Priority: Major > > The largest cost of the export handler is the sorting. This ticket will > implement an improved algorithm for sorting that should greatly increase > overall throughput for the export handler. > *The current algorithm is as follows:* > Collect a bitset of matching docs. Iterate over that bitset and materialize > the top level oridinals for the sort fields in the document and add them to > priority queue of size 3. Then export the top 3 docs, turn off the > bits in the bit set and iterate again until all docs are sorted and sent. > There are two performance bottlenecks with this approach: > 1) Materializing the top level ordinals adds a huge amount of overhead to the > sorting process. > 2) The size of priority queue, 30,000, adds significant overhead to sorting > operations. > *The new algorithm:* > Has a top level *merge sort iterator* that wraps segment level iterators that > perform segment level priority queue sorts. > *Segment level:* > The segment level docset will be iterated and the segment level ordinals for > the sort fields will be materialized and added to a segment level priority > queue. As the segment level iterator pops docs from the priority queue the > top level ordinals for the sort fields are materialized. Because the top > level ordinals are materialized AFTER the sort, they only need to be looked > up when the segment level ordinal changes. This takes advantage of the sort > to limit the lookups into the top level ordinal structures. This also > eliminates redundant lookups of top level ordinals that occur during the > multiple passes over the matching docset. > The segment level priority queues can be kept smaller than 30,000 to improve > performance of the sorting operations because the overall batch size will > still be 30,000 or greater when all the segment priority queue sizes are > added up. This allows for batch sizes much larger then 30,000 without using a > single large priority queue. The increased batch size means fewer iterations > over the matching docset and the decreased priority queue size means faster > sorting operations. > *Top level:* > A top level iterator does a merge sort over the segment level iterators by > comparing the top level ordinals materialized when the segment level docs are > popped from the segment level priority queues. This requires no extra memory > and will be very performant. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9440) FieldInfo#checkConsistency called twice from Lucene50(60)FieldInfosFormat#read
[
https://issues.apache.org/jira/browse/LUCENE-9440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167138#comment-17167138
]
Yauheni Putsykovich commented on LUCENE-9440:
-
So, what do you think?
> FieldInfo#checkConsistency called twice from Lucene50(60)FieldInfosFormat#read
> --
>
> Key: LUCENE-9440
> URL: https://issues.apache.org/jira/browse/LUCENE-9440
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
>Affects Versions: master (9.0)
>Reporter: Yauheni Putsykovich
>Priority: Trivial
> Attachments: LUCENE-9440.patch, LUCENE-9440.patch
>
>
> Reviewing code I noticed that we do call _infos[i].checkConsistency();_
> method twice: first time inside the _FiledInfo_'s constructor and a second
> one just after we've created an object.
> org/apache/lucene/codecs/lucene50/Lucene50FieldInfosFormat.java:150
> {code:java}
> infos[i] = new FieldInfo(name, fieldNumber, storeTermVector, omitNorms,
> storePayloads, indexOptions, docValuesType, dvGen, attributes, 0, 0, 0,
> false);
> infos[i].checkConsistency();
> {code}
> _FileInfo_'s constructor(notice the last line)
> {code:java}
> public FieldInfo(String name, int number, boolean storeTermVector, boolean
> omitNorms, boolean storePayloads,
> IndexOptions indexOptions, DocValuesType docValues, long
> dvGen, Map attributes,
> int pointDimensionCount, int pointIndexDimensionCount, int
> pointNumBytes, boolean softDeletesField) {
> this.name = Objects.requireNonNull(name);
> this.number = number;
> this.docValuesType = Objects.requireNonNull(docValues, "DocValuesType must
> not be null (field: \"" + name + "\")");
> this.indexOptions = Objects.requireNonNull(indexOptions, "IndexOptions must
> not be null (field: \"" + name + "\")");
> if (indexOptions != IndexOptions.NONE) {
> this.storeTermVector = storeTermVector;
> this.storePayloads = storePayloads;
> this.omitNorms = omitNorms;
> } else { // for non-indexed fields, leave defaults
> this.storeTermVector = false;
> this.storePayloads = false;
> this.omitNorms = false;
> }
> this.dvGen = dvGen;
> this.attributes = Objects.requireNonNull(attributes);
> this.pointDimensionCount = pointDimensionCount;
> this.pointIndexDimensionCount = pointIndexDimensionCount;
> this.pointNumBytes = pointNumBytes;
> this.softDeletesField = softDeletesField;
> assert checkConsistency();
> }
> {code}
>
> By this patch, I will remove the second call and leave only one in the
> constructor.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14689) Convert streaming expressions into packages
[ https://issues.apache.org/jira/browse/SOLR-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167197#comment-17167197 ] Joel Bernstein commented on SOLR-14689: --- So it sounds like in this ticket the main goal is the move to a contrib that lives within the Solr project. Is that correct? > Convert streaming expressions into packages > --- > > Key: SOLR-14689 > URL: https://issues.apache.org/jira/browse/SOLR-14689 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > > Streaming expressions should be converted to packages so that: > # The SolrJ package is leaner > # Streaming expressions can have a faster release cycle > # We can invite more contributions for streaming expressions and also > encourage third party streaming expressions. > In this issue, let us achieve the following: > # Isolate the streaming expressions into a contrib module first so that a jar > file can be built out of that. The StreamingHandler can stay in Solr-core. > # Instead of all the 300+ expressions be added to configset (via > solrconfig.xml or Config API), let us build a streaming expressions factory > that registers all of the named expressions at once. > # Eventually, once we're done with the above two steps, we can worry about > signing, distribution etc., as per SOLR-14688. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14689) Convert streaming expressions into packages
[ https://issues.apache.org/jira/browse/SOLR-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167201#comment-17167201 ] Joel Bernstein commented on SOLR-14689: --- The only thing to consider with this is the JDBC driver. Right now the JDBC driver comes with Solrj. Now it will need a separate jar. > Convert streaming expressions into packages > --- > > Key: SOLR-14689 > URL: https://issues.apache.org/jira/browse/SOLR-14689 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > > Streaming expressions should be converted to packages so that: > # The SolrJ package is leaner > # Streaming expressions can have a faster release cycle > # We can invite more contributions for streaming expressions and also > encourage third party streaming expressions. > In this issue, let us achieve the following: > # Isolate the streaming expressions into a contrib module first so that a jar > file can be built out of that. The StreamingHandler can stay in Solr-core. > # Instead of all the 300+ expressions be added to configset (via > solrconfig.xml or Config API), let us build a streaming expressions factory > that registers all of the named expressions at once. > # Eventually, once we're done with the above two steps, we can worry about > signing, distribution etc., as per SOLR-14688. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9376) Fix or suppress 20 resource leak precommit warnings in lucene/search
[
https://issues.apache.org/jira/browse/LUCENE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167204#comment-17167204
]
Erick Erickson commented on LUCENE-9376:
[~dsmiley] So do you want me to fix it up or is this just informational?
> Fix or suppress 20 resource leak precommit warnings in lucene/search
>
>
> Key: LUCENE-9376
> URL: https://issues.apache.org/jira/browse/LUCENE-9376
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Andras Salamon
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 8.6
>
> Attachments: LUCENE-9376.patch
>
>
> There are 20 resource leak precommit warnings in org/apache/lucene/search:
> {noformat}
> [ecj-lint] 71. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 414)
> [ecj-lint] MockAnalyzer analyzer = new MockAnalyzer(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 72. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 557)
> [ecj-lint] RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> [ecj-lint] ^
> [ecj-lint] Resource leak: 'w' is never closed
> --
> [ecj-lint] 73. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'mgr' is not closed at this location
> --
> [ecj-lint] 74. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'w' is not closed at this location
> --
> [ecj-lint] 75. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSameScoresWithThreads.java
> (at line 49)
> [ecj-lint] LineFileDocs docs = new LineFileDocs(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'docs' is never closed
> --
> [ecj-lint] 76. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSearcherManager.java
> (at line 313)
> [ecj-lint] SearcherManager sm = new SearcherManager(writer, false, false,
> new SearcherFactory());
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'sm' is never closed
> --
> [ecj-lint] 79. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestTermQuery.java
> (at line 52)
> [ecj-lint] new TermQuery(new Term("foo", "bar"), TermStates.build(new
> MultiReader().getContext(), new Term("foo", "bar"), true)));
> [ecj-lint]
> ^
> [ecj-lint] Resource leak: '' is never closed
> --
> [ecj-lint] 15. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/test-framework/src/java/org/apache/lucene/search/ShardSearchingTestBase.java
> (at line 554)
> [ecj-lint] final LineFileDocs docs = new LineFileDocs(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'docs' is never closed
> --
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/UnifiedHighlighter.java
> (at line 598)
> [ecj-lint] IndexReader indexReaderWithTermVecCache =
> [ecj-lint] ^^^
> [ecj-lint] Resource leak: 'indexReaderWithTermVecCache' is never closed
> --
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/HighlighterTest.java
> (at line 1365)
> [ecj-lint] Analyzer analyzer = new SynonymAnalyzer(synonyms);
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 2. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/TokenSourcesTest.java
> (at line 379)
> [ecj-lint] final BaseTermVectorsFormatTestCase.RandomTokenStream
> rTokenStream =
> [ecj-lint]
>
> [ecj-lint] Resource leak: 'rTokenStream' is never closed
> --
> [ecj-lint] 3. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/custom/HighlightCustomQueryTest.java
> (at line 108)
> [ec
[jira] [Updated] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Robert Miller updated SOLR-14636:
--
Attachment: jenkins.png
Status: Open (was: Open)
Here is my local Jenkins cluster - it runs tests on a std real linux box, vms
on two different macs with 1-4 cpus allowed. I have a couple weak windows boxes
and another linux box I'll eventually throw back into the mix. I have enough
history kept to cover about 9-12 hours, so no last known failure is about that
long. The current failure indicated was the audit log executor - that sneaky
guy, how does he do it? Escape artist.
!jenkins.png!
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg, jenkins.png
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> *tests***:
> * *core*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: *extremely stable* with {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: *extremely stable* with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*extremely
> stable*{color} with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*extremely
> stable*{color} with {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*extremely stable*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14689) Convert streaming expressions into packages
[
https://issues.apache.org/jira/browse/SOLR-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167216#comment-17167216
]
Jan Høydahl commented on SOLR-14689:
Great if this can be first step in slimming SolrJ as well. If the JDBC parts
are easily isolated into a {{solrj-jdbc}} jar then we just need to document
that users need it in order to use JDBC with streaming/SQL?
> Convert streaming expressions into packages
> ---
>
> Key: SOLR-14689
> URL: https://issues.apache.org/jira/browse/SOLR-14689
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>
> Streaming expressions should be converted to packages so that:
> # The SolrJ package is leaner
> # Streaming expressions can have a faster release cycle
> # We can invite more contributions for streaming expressions and also
> encourage third party streaming expressions.
> In this issue, let us achieve the following:
> # Isolate the streaming expressions into a contrib module first so that a jar
> file can be built out of that. The StreamingHandler can stay in Solr-core.
> # Instead of all the 300+ expressions be added to configset (via
> solrconfig.xml or Config API), let us build a streaming expressions factory
> that registers all of the named expressions at once.
> # Eventually, once we're done with the above two steps, we can worry about
> signing, distribution etc., as per SOLR-14688.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9416) Fix CheckIndex to print norms as unsigned integers
[ https://issues.apache.org/jira/browse/LUCENE-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167224#comment-17167224 ] Michael McCandless commented on LUCENE-9416: Thanks [~mosadiq] – I'll commit your patch soon! > Fix CheckIndex to print norms as unsigned integers > -- > > Key: LUCENE-9416 > URL: https://issues.apache.org/jira/browse/LUCENE-9416 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Reporter: Mohammad Sadiq >Priority: Minor > Attachments: LUCENE-9416.patch > > > In the [discussion on "CheckIndex complaining about -1 for norms value" in > the java-user list|http://markmail.org/message/gcwdhasblsyovwc2], it was > identified that we should "fix CheckIndex to print norms as unsigned > integers". > I'd like to take a stab at this. > I'm trying to understand the problem and from what I gather, while norms are > `byte`s, the API exposes them as `long` values. While printing the error > message, we want it to print a zero instead of -1? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14691) Metrics reporting should avoid creating objects
Andrzej Bialecki created SOLR-14691:
---
Summary: Metrics reporting should avoid creating objects
Key: SOLR-14691
URL: https://issues.apache.org/jira/browse/SOLR-14691
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: metrics
Reporter: Andrzej Bialecki
{{MetricUtils}} unnecessarily creates a lot of short-lived objects (maps and
lists). This affects GC, especially since metrics are frequently polled by
clients. We should refactor it to use {{MapWriter}} as much as possible.
Alternatively we could provide our wrappers or subclasses of Codahale metrics
that implement {{MapWriter}}, then a lot of complexity in {{MetricUtils}}
wouldn't be needed at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14689) Convert streaming expressions into packages
[ https://issues.apache.org/jira/browse/SOLR-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167234#comment-17167234 ] Ishan Chattopadhyaya commented on SOLR-14689: - I think we should have a separate solrj-jdbc-VERSION.jar, and move it outside SolrJ. That doesn't need to be a Solr "package", but just artifacts that are released in Maven (just like SolrJ jars). > Convert streaming expressions into packages > --- > > Key: SOLR-14689 > URL: https://issues.apache.org/jira/browse/SOLR-14689 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > > Streaming expressions should be converted to packages so that: > # The SolrJ package is leaner > # Streaming expressions can have a faster release cycle > # We can invite more contributions for streaming expressions and also > encourage third party streaming expressions. > In this issue, let us achieve the following: > # Isolate the streaming expressions into a contrib module first so that a jar > file can be built out of that. The StreamingHandler can stay in Solr-core. > # Instead of all the 300+ expressions be added to configset (via > solrconfig.xml or Config API), let us build a streaming expressions factory > that registers all of the named expressions at once. > # Eventually, once we're done with the above two steps, we can worry about > signing, distribution etc., as per SOLR-14688. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14689) Convert streaming expressions into packages
[ https://issues.apache.org/jira/browse/SOLR-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167237#comment-17167237 ] Ishan Chattopadhyaya commented on SOLR-14689: - bq. So it sounds like in this ticket the main goal is the move to a contrib that lives within the Solr project. Is that correct? Right, main goal of this ticket. End product to be a jar, and a way to use that jar in a running Solr instance. Once this is avhieved, converting this into a package is probably trivial/easy (matter of placing the jar in the right place, writing up a metadata.json, repository.json etc.). > Convert streaming expressions into packages > --- > > Key: SOLR-14689 > URL: https://issues.apache.org/jira/browse/SOLR-14689 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > > Streaming expressions should be converted to packages so that: > # The SolrJ package is leaner > # Streaming expressions can have a faster release cycle > # We can invite more contributions for streaming expressions and also > encourage third party streaming expressions. > In this issue, let us achieve the following: > # Isolate the streaming expressions into a contrib module first so that a jar > file can be built out of that. The StreamingHandler can stay in Solr-core. > # Instead of all the 300+ expressions be added to configset (via > solrconfig.xml or Config API), let us build a streaming expressions factory > that registers all of the named expressions at once. > # Eventually, once we're done with the above two steps, we can worry about > signing, distribution etc., as per SOLR-14688. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9416) Fix CheckIndex to print norms as unsigned integers
[ https://issues.apache.org/jira/browse/LUCENE-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167240#comment-17167240 ] ASF subversion and git services commented on LUCENE-9416: - Commit 327d860a00cb2a64887f4b4c322cba5e6daec8e8 in lucene-solr's branch refs/heads/master from Michael McCandless [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=327d860 ] LUCENE-9416: fix CheckIndex to print an invalid non-zero norm as unsigned long when detecting corruption > Fix CheckIndex to print norms as unsigned integers > -- > > Key: LUCENE-9416 > URL: https://issues.apache.org/jira/browse/LUCENE-9416 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Reporter: Mohammad Sadiq >Priority: Minor > Attachments: LUCENE-9416.patch > > > In the [discussion on "CheckIndex complaining about -1 for norms value" in > the java-user list|http://markmail.org/message/gcwdhasblsyovwc2], it was > identified that we should "fix CheckIndex to print norms as unsigned > integers". > I'd like to take a stab at this. > I'm trying to understand the problem and from what I gather, while norms are > `byte`s, the API exposes them as `long` values. While printing the error > message, we want it to print a zero instead of -1? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9416) Fix CheckIndex to print norms as unsigned integers
[ https://issues.apache.org/jira/browse/LUCENE-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167241#comment-17167241 ] ASF subversion and git services commented on LUCENE-9416: - Commit b339f98fcbcaf6b1a7279410fefc0cb11ea5fa2c in lucene-solr's branch refs/heads/branch_8x from Michael McCandless [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b339f98 ] LUCENE-9416: fix CheckIndex to print an invalid non-zero norm as unsigned long when detecting corruption > Fix CheckIndex to print norms as unsigned integers > -- > > Key: LUCENE-9416 > URL: https://issues.apache.org/jira/browse/LUCENE-9416 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Reporter: Mohammad Sadiq >Priority: Minor > Attachments: LUCENE-9416.patch > > > In the [discussion on "CheckIndex complaining about -1 for norms value" in > the java-user list|http://markmail.org/message/gcwdhasblsyovwc2], it was > identified that we should "fix CheckIndex to print norms as unsigned > integers". > I'd like to take a stab at this. > I'm trying to understand the problem and from what I gather, while norms are > `byte`s, the API exposes them as `long` values. While printing the error > message, we want it to print a zero instead of -1? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9416) Fix CheckIndex to print norms as unsigned integers
[ https://issues.apache.org/jira/browse/LUCENE-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-9416: --- Fix Version/s: 8.7 master (9.0) Resolution: Fixed Status: Resolved (was: Patch Available) Thanks [~mosadiq]! > Fix CheckIndex to print norms as unsigned integers > -- > > Key: LUCENE-9416 > URL: https://issues.apache.org/jira/browse/LUCENE-9416 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Reporter: Mohammad Sadiq >Priority: Minor > Fix For: master (9.0), 8.7 > > Attachments: LUCENE-9416.patch > > > In the [discussion on "CheckIndex complaining about -1 for norms value" in > the java-user list|http://markmail.org/message/gcwdhasblsyovwc2], it was > identified that we should "fix CheckIndex to print norms as unsigned > integers". > I'd like to take a stab at this. > I'm trying to understand the problem and from what I gather, while norms are > `byte`s, the API exposes them as `long` values. While printing the error > message, we want it to print a zero instead of -1? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9443) "IndexReader is closed" regression in highlighter
Chris Beer created LUCENE-9443: -- Summary: "IndexReader is closed" regression in highlighter Key: LUCENE-9443 URL: https://issues.apache.org/jira/browse/LUCENE-9443 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 8.6 Reporter: Chris Beer I'm seeing a regression the UnifiedHighlighter (observed in Solr 8.6, leading to a crashed core), likely caused by LUCENE-9376 ([https://github.com/apache/lucene-solr/commit/8e578b4e51cbab206c31653077ce4a3e3a6879b8#diff-f545e503a21f7331f0706fb89f7c663eR648?)] [~dsmiley] adds: [the] call to close indexReaderWithTermVecCache but this is a wrapper IndexReader that is not supposed to be closed. It'll close the underlying real reader if you do which is nasty as that's the live one, which thus brings down the core. This is reproducible with Solr 8.6, a trivial configuration ([https://gist.github.com/cbeer/6d3191918b39e3e83e80ac48c00de925),] and an empty index with a request like: http://127.0.0.1:8983/solr/blacklight-core/select?q=id:[*+TO+*]&hl=true&hl.fl=full_text_search_en+full_text_search_pt&hl.offsetSource=postings_with_term_vectors&hl.method=unified -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9376) Fix or suppress 20 resource leak precommit warnings in lucene/search
[
https://issues.apache.org/jira/browse/LUCENE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167260#comment-17167260
]
David Smiley commented on LUCENE-9376:
--
I will submit a fix for that today for 8.6.1
> Fix or suppress 20 resource leak precommit warnings in lucene/search
>
>
> Key: LUCENE-9376
> URL: https://issues.apache.org/jira/browse/LUCENE-9376
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Andras Salamon
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 8.6
>
> Attachments: LUCENE-9376.patch
>
>
> There are 20 resource leak precommit warnings in org/apache/lucene/search:
> {noformat}
> [ecj-lint] 71. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 414)
> [ecj-lint] MockAnalyzer analyzer = new MockAnalyzer(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 72. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 557)
> [ecj-lint] RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> [ecj-lint] ^
> [ecj-lint] Resource leak: 'w' is never closed
> --
> [ecj-lint] 73. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'mgr' is not closed at this location
> --
> [ecj-lint] 74. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'w' is not closed at this location
> --
> [ecj-lint] 75. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSameScoresWithThreads.java
> (at line 49)
> [ecj-lint] LineFileDocs docs = new LineFileDocs(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'docs' is never closed
> --
> [ecj-lint] 76. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSearcherManager.java
> (at line 313)
> [ecj-lint] SearcherManager sm = new SearcherManager(writer, false, false,
> new SearcherFactory());
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'sm' is never closed
> --
> [ecj-lint] 79. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestTermQuery.java
> (at line 52)
> [ecj-lint] new TermQuery(new Term("foo", "bar"), TermStates.build(new
> MultiReader().getContext(), new Term("foo", "bar"), true)));
> [ecj-lint]
> ^
> [ecj-lint] Resource leak: '' is never closed
> --
> [ecj-lint] 15. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/test-framework/src/java/org/apache/lucene/search/ShardSearchingTestBase.java
> (at line 554)
> [ecj-lint] final LineFileDocs docs = new LineFileDocs(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'docs' is never closed
> --
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/UnifiedHighlighter.java
> (at line 598)
> [ecj-lint] IndexReader indexReaderWithTermVecCache =
> [ecj-lint] ^^^
> [ecj-lint] Resource leak: 'indexReaderWithTermVecCache' is never closed
> --
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/HighlighterTest.java
> (at line 1365)
> [ecj-lint] Analyzer analyzer = new SynonymAnalyzer(synonyms);
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 2. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/TokenSourcesTest.java
> (at line 379)
> [ecj-lint] final BaseTermVectorsFormatTestCase.RandomTokenStream
> rTokenStream =
> [ecj-lint]
>
> [ecj-lint] Resource leak: 'rTokenStream' is never closed
> --
> [ecj-lint] 3. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/custom/HighlightCustomQueryTest.java
> (at line 108)
> [ecj-lint] TokenStream tokenStrea
[jira] [Commented] (SOLR-14671) NumberFormatException on ZK Status page when client port missing in dynamic config
[
https://issues.apache.org/jira/browse/SOLR-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167261#comment-17167261
]
Henrik commented on SOLR-14671:
---
Just to confirm: Adding the clientPort to the server.n entries in zoo.cfg fixed
this issue.
Example error config:
{code}
clientPort = 7793
server.1 = dev-confluentzoo2014.example.com:7795:7796
{code}
Example working config:
{code}
server.1 = dev-confluentzoo2014.example.com:7795:7796;7793
{code}
> NumberFormatException on ZK Status page when client port missing in dynamic
> config
> --
>
> Key: SOLR-14671
> URL: https://issues.apache.org/jira/browse/SOLR-14671
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, SolrCloud
>Affects Versions: 8.6
>Reporter: Henrik
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The Admin -> Cloud -> ZK Status page in Solr 8.6.0 does not show any data
> except for the error message "null". I get the following exception in
> solr.log:
> {code:java}
> ERROR [20200721T081301,835] qtp478489615-21
> org.apache.solr.handler.RequestHandlerBase - java.lang.NumberFormatException:
> null
> at java.base/java.lang.Integer.parseInt(Integer.java:620)
> at java.base/java.lang.Integer.parseInt(Integer.java:776)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig$Server.parseLine(ZkDynamicConfig.java:142)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.lambda$parseLines$0(ZkDynamicConfig.java:58)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.parseLines(ZkDynamicConfig.java:53)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:3
[jira] [Commented] (SOLR-14671) NumberFormatException on ZK Status page when client port missing in dynamic config
[
https://issues.apache.org/jira/browse/SOLR-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167263#comment-17167263
]
Jan Høydahl commented on SOLR-14671:
Thanks for confirming, Henrik!
> NumberFormatException on ZK Status page when client port missing in dynamic
> config
> --
>
> Key: SOLR-14671
> URL: https://issues.apache.org/jira/browse/SOLR-14671
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, SolrCloud
>Affects Versions: 8.6
>Reporter: Henrik
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The Admin -> Cloud -> ZK Status page in Solr 8.6.0 does not show any data
> except for the error message "null". I get the following exception in
> solr.log:
> {code:java}
> ERROR [20200721T081301,835] qtp478489615-21
> org.apache.solr.handler.RequestHandlerBase - java.lang.NumberFormatException:
> null
> at java.base/java.lang.Integer.parseInt(Integer.java:620)
> at java.base/java.lang.Integer.parseInt(Integer.java:776)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig$Server.parseLine(ZkDynamicConfig.java:142)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.lambda$parseLines$0(ZkDynamicConfig.java:58)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.parseLines(ZkDynamicConfig.java:53)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(
[jira] [Commented] (SOLR-14689) Convert streaming expressions into packages
[ https://issues.apache.org/jira/browse/SOLR-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167268#comment-17167268 ] Joel Bernstein commented on SOLR-14689: --- Having a separate JDBC shaded jar is major step forward, +1 if we can make that happen with this ticket. > Convert streaming expressions into packages > --- > > Key: SOLR-14689 > URL: https://issues.apache.org/jira/browse/SOLR-14689 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > > Streaming expressions should be converted to packages so that: > # The SolrJ package is leaner > # Streaming expressions can have a faster release cycle > # We can invite more contributions for streaming expressions and also > encourage third party streaming expressions. > In this issue, let us achieve the following: > # Isolate the streaming expressions into a contrib module first so that a jar > file can be built out of that. The StreamingHandler can stay in Solr-core. > # Instead of all the 300+ expressions be added to configset (via > solrconfig.xml or Config API), let us build a streaming expressions factory > that registers all of the named expressions at once. > # Eventually, once we're done with the above two steps, we can worry about > signing, distribution etc., as per SOLR-14688. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13205) StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
[
https://issues.apache.org/jira/browse/SOLR-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167272#comment-17167272
]
ASF subversion and git services commented on SOLR-13205:
Commit c73db65dbf694305489f6d6d92e4c7fd71981a03 in lucene-solr's branch
refs/heads/branch_8x from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c73db65 ]
SOLR-13205: Improve empty-string handling in SolrQueryParserBase
This was previously committed and reverted on branch_8x due to a test
failure in the backport. This updated commit fixes that test failure by
removing an unnecessary/invalid 'luceneMatchVersion' check that wasn't
present on other branches.
Co-authored-by: pramodkumar9
> StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
>
>
> Key: SOLR-13205
> URL: https://issues.apache.org/jira/browse/SOLR-13205
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (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 and reproducing the bug
> 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].
> {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
> curl -v “URL_BUG”
> {noformat}
> Please check the issue description below to find the “URL_BUG” that will
> allow you to reproduce the issue reported.
>Reporter: Johannes Kloos
>Assignee: Jason Gerlowski
>Priority: Minor
> Labels: diffblue, newdev
> Fix For: master (9.0), 8.7
>
> Attachments: SOLR-13205.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?df=&explainOther=debug=all&debugQuery=on
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> at java.lang.String.charAt(String.java:658)
> at
> org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:1045)
> at
> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:801)
> at org.apache.solr.parser.QueryParser.Term(QueryParser.java:421)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:278)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)
> at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:131)
> at
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:255)
> at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:49)
> at org.apache.solr.search.QParser.getQuery(QParser.java:173)
> at
> org.apache.solr.util.SolrPluginUtils.doSimpleQuery(SolrPluginUtils.java:479)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardResultsDebug(SolrPluginUtils.java:390)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardDebug(SolrPluginUtils.java:343)
> at
> org.apache.solr.handler.component.DebugComponent.process(DebugComponent.java:100)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:306)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> {noformat}
> The “df” parameter means that we set the empty string as default field(!).
> Since we do not give a field in the query, the default field is substituted
> in getFieldQuery. We then chec
[jira] [Resolved] (SOLR-13205) StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
[
https://issues.apache.org/jira/browse/SOLR-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski resolved SOLR-13205.
Resolution: Fixed
Got a fix back on branch_8x. Thanks everyone.
> StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
>
>
> Key: SOLR-13205
> URL: https://issues.apache.org/jira/browse/SOLR-13205
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (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 and reproducing the bug
> 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].
> {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
> curl -v “URL_BUG”
> {noformat}
> Please check the issue description below to find the “URL_BUG” that will
> allow you to reproduce the issue reported.
>Reporter: Johannes Kloos
>Assignee: Jason Gerlowski
>Priority: Minor
> Labels: diffblue, newdev
> Fix For: master (9.0), 8.7
>
> Attachments: SOLR-13205.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?df=&explainOther=debug=all&debugQuery=on
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> at java.lang.String.charAt(String.java:658)
> at
> org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:1045)
> at
> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:801)
> at org.apache.solr.parser.QueryParser.Term(QueryParser.java:421)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:278)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)
> at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:131)
> at
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:255)
> at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:49)
> at org.apache.solr.search.QParser.getQuery(QParser.java:173)
> at
> org.apache.solr.util.SolrPluginUtils.doSimpleQuery(SolrPluginUtils.java:479)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardResultsDebug(SolrPluginUtils.java:390)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardDebug(SolrPluginUtils.java:343)
> at
> org.apache.solr.handler.component.DebugComponent.process(DebugComponent.java:100)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:306)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> {noformat}
> The “df” parameter means that we set the empty string as default field(!).
> Since we do not give a field in the query, the default field is substituted
> in getFieldQuery. We then check if the field starts with “_” by using
> charAt(0).
> A trivial fix would be to replace field.charAt(0) == ‘_’ with
> field.startsWith(“_”).
> To set up an environment to reproduce this bug, follow the description in the
> ‘Environment’ field.
> We automatically found this issue and ~70 more like this using [Diffblue
> Microservices Testing|https://www.diffblue.com/labs/?utm_source=solr-br].
> Find more information on this [fuzz testing
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-pee
[jira] [Created] (SOLR-14692) JSON Facet "join" domain should take optional "method" property
Jason Gerlowski created SOLR-14692: -- Summary: JSON Facet "join" domain should take optional "method" property Key: SOLR-14692 URL: https://issues.apache.org/jira/browse/SOLR-14692 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: faceting, JSON Request API Affects Versions: 8.6, master (9.0) Reporter: Jason Gerlowski Solr offers several different join implementations which can be switched off providing the "method" local-param on JoinQuery's. Each of these implementations has different performance characteristics and can behave very differently depending on a user's data and use case. When joins are used internally as a part of JSON Faceting's "join" domain-transform though, users have no way to specify which implementation they would like to use. We should correct this by adding a "method" property to the join domain-transform. This will let user's choose the join that's most performant for their use case during JSON Facet requests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14671) NumberFormatException on ZK Status page when client port missing in dynamic config
[
https://issues.apache.org/jira/browse/SOLR-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167325#comment-17167325
]
Aliaksei Zhynhiarouski commented on SOLR-14671:
---
I did correct configuration as Henrik mentioned and everything works fine,
thanks!
> NumberFormatException on ZK Status page when client port missing in dynamic
> config
> --
>
> Key: SOLR-14671
> URL: https://issues.apache.org/jira/browse/SOLR-14671
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, SolrCloud
>Affects Versions: 8.6
>Reporter: Henrik
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The Admin -> Cloud -> ZK Status page in Solr 8.6.0 does not show any data
> except for the error message "null". I get the following exception in
> solr.log:
> {code:java}
> ERROR [20200721T081301,835] qtp478489615-21
> org.apache.solr.handler.RequestHandlerBase - java.lang.NumberFormatException:
> null
> at java.base/java.lang.Integer.parseInt(Integer.java:620)
> at java.base/java.lang.Integer.parseInt(Integer.java:776)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig$Server.parseLine(ZkDynamicConfig.java:142)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.lambda$parseLines$0(ZkDynamicConfig.java:58)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.parseLines(ZkDynamicConfig.java:53)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractC
[jira] [Commented] (LUCENE-9376) Fix or suppress 20 resource leak precommit warnings in lucene/search
[
https://issues.apache.org/jira/browse/LUCENE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167350#comment-17167350
]
Erick Erickson commented on LUCENE-9376:
OK, thanks. Sorry for the noise.
> Fix or suppress 20 resource leak precommit warnings in lucene/search
>
>
> Key: LUCENE-9376
> URL: https://issues.apache.org/jira/browse/LUCENE-9376
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Andras Salamon
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 8.6
>
> Attachments: LUCENE-9376.patch
>
>
> There are 20 resource leak precommit warnings in org/apache/lucene/search:
> {noformat}
> [ecj-lint] 71. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 414)
> [ecj-lint] MockAnalyzer analyzer = new MockAnalyzer(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 72. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 557)
> [ecj-lint] RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> [ecj-lint] ^
> [ecj-lint] Resource leak: 'w' is never closed
> --
> [ecj-lint] 73. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'mgr' is not closed at this location
> --
> [ecj-lint] 74. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'w' is not closed at this location
> --
> [ecj-lint] 75. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSameScoresWithThreads.java
> (at line 49)
> [ecj-lint] LineFileDocs docs = new LineFileDocs(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'docs' is never closed
> --
> [ecj-lint] 76. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSearcherManager.java
> (at line 313)
> [ecj-lint] SearcherManager sm = new SearcherManager(writer, false, false,
> new SearcherFactory());
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'sm' is never closed
> --
> [ecj-lint] 79. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestTermQuery.java
> (at line 52)
> [ecj-lint] new TermQuery(new Term("foo", "bar"), TermStates.build(new
> MultiReader().getContext(), new Term("foo", "bar"), true)));
> [ecj-lint]
> ^
> [ecj-lint] Resource leak: '' is never closed
> --
> [ecj-lint] 15. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/test-framework/src/java/org/apache/lucene/search/ShardSearchingTestBase.java
> (at line 554)
> [ecj-lint] final LineFileDocs docs = new LineFileDocs(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'docs' is never closed
> --
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/UnifiedHighlighter.java
> (at line 598)
> [ecj-lint] IndexReader indexReaderWithTermVecCache =
> [ecj-lint] ^^^
> [ecj-lint] Resource leak: 'indexReaderWithTermVecCache' is never closed
> --
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/HighlighterTest.java
> (at line 1365)
> [ecj-lint] Analyzer analyzer = new SynonymAnalyzer(synonyms);
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 2. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/TokenSourcesTest.java
> (at line 379)
> [ecj-lint] final BaseTermVectorsFormatTestCase.RandomTokenStream
> rTokenStream =
> [ecj-lint]
>
> [ecj-lint] Resource leak: 'rTokenStream' is never closed
> --
> [ecj-lint] 3. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/custom/HighlightCustomQueryTest.java
> (at line 108)
> [ecj-lint] TokenStream tokenStream = new
[jira] [Created] (SOLR-14693) Using `fl=[explain]` (ExplainAugmenterFactory) does not work when grouping is enabled and collection has only one shard
Charles Burnett created SOLR-14693: -- Summary: Using `fl=[explain]` (ExplainAugmenterFactory) does not work when grouping is enabled and collection has only one shard Key: SOLR-14693 URL: https://issues.apache.org/jira/browse/SOLR-14693 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Affects Versions: 8.4.1 Environment: Linux kernel 5.4.0-42-generic OpenJDK 64-bit Server VM 11.0.8 11.0.8+10 Reporter: Charles Burnett Explain field is added, as expected, in the following scenarios: * Grouping is disabled * Grouping is enabled and collection has more than one shard Explain field is NOT added to documents in the following scenario: * Grouping is enabled and collection has only one shard -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] henrik242 commented on a change in pull request #1701: SOLR-14671: Parsing dynamic ZK config sometimes cause NuberFormatException
henrik242 commented on a change in pull request #1701: URL: https://github.com/apache/lucene-solr/pull/1701#discussion_r462134434 ## File path: solr/CHANGES.txt ## @@ -164,6 +164,13 @@ Other Changes * SOLR-11868: Deprecate CloudSolrClient.setIdField, use information from Zookeeper (Erick Erickson) +== 8.6.1 == + +Bug Fixes +- + +* SOLR-14671: Parsing dynamic ZK config sometimes cause NuberFormatException (janhoy) Review comment: @janhoy Typo in Nu[m]berFormatException 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] cpoerschke commented on a change in pull request #1571: SOLR-14560: Interleaving for Learning To Rank
cpoerschke commented on a change in pull request #1571:
URL: https://github.com/apache/lucene-solr/pull/1571#discussion_r462456864
##
File path:
solr/contrib/ltr/src/java/org/apache/solr/ltr/search/LTRQParserPlugin.java
##
@@ -146,93 +149,114 @@ public LTRQParser(String qstr, SolrParams localParams,
SolrParams params,
@Override
public Query parse() throws SyntaxError {
// ReRanking Model
- final String modelName = localParams.get(LTRQParserPlugin.MODEL);
- if ((modelName == null) || modelName.isEmpty()) {
+ final String[] modelNames =
localParams.getParams(LTRQParserPlugin.MODEL);
+ if ((modelNames == null) || modelNames.length==0 ||
modelNames[0].isEmpty()) {
throw new SolrException(SolrException.ErrorCode.BAD_REQUEST,
"Must provide model in the request");
}
-
- final LTRScoringModel ltrScoringModel = mr.getModel(modelName);
- if (ltrScoringModel == null) {
-throw new SolrException(SolrException.ErrorCode.BAD_REQUEST,
-"cannot find " + LTRQParserPlugin.MODEL + " " + modelName);
- }
-
- final String modelFeatureStoreName =
ltrScoringModel.getFeatureStoreName();
- final boolean extractFeatures =
SolrQueryRequestContextUtils.isExtractingFeatures(req);
- final String fvStoreName =
SolrQueryRequestContextUtils.getFvStoreName(req);
- // Check if features are requested and if the model feature store and
feature-transform feature store are the same
- final boolean featuresRequestedFromSameStore =
(modelFeatureStoreName.equals(fvStoreName) || fvStoreName == null) ?
extractFeatures:false;
- if (threadManager != null) {
-
threadManager.setExecutor(req.getCore().getCoreContainer().getUpdateShardHandler().getUpdateExecutor());
- }
- final LTRScoringQuery scoringQuery = new LTRScoringQuery(ltrScoringModel,
- extractEFIParams(localParams),
- featuresRequestedFromSameStore, threadManager);
-
- // Enable the feature vector caching if we are extracting features, and
the features
- // we requested are the same ones we are reranking with
- if (featuresRequestedFromSameStore) {
-scoringQuery.setFeatureLogger(
SolrQueryRequestContextUtils.getFeatureLogger(req) );
+
+ LTRScoringQuery[] rerankingQueries = new
LTRScoringQuery[modelNames.length];
+ for (int i = 0; i < modelNames.length; i++) {
+final LTRScoringQuery rerankingQuery;
+if (!ORIGINAL_RANKING.equals(modelNames[i])) {
Review comment:
The model name `originalRanking` is being given a special meaning here.
I wonder if perhaps the differences between models could be transferred to the
parameter names somehow (e.g. a new `original_model` parameter name alongside
the existing `model` parameter name)? Then users could choose any model name
they like, including for "original ranking" purposes.
https://github.com/apache/lucene-solr/pull/1705 proposes to factor out a
`LTRQParserPlugin.newLTRScoringQuery` method (but I haven't yet explored fully
w.r.t. how that might connect up here w.r.t. additional parameter names).
What do you think?
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-9443) "IndexReader is closed" regression in highlighter
[ https://issues.apache.org/jira/browse/LUCENE-9443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley reassigned LUCENE-9443: Assignee: David Smiley > "IndexReader is closed" regression in highlighter > - > > Key: LUCENE-9443 > URL: https://issues.apache.org/jira/browse/LUCENE-9443 > Project: Lucene - Core > Issue Type: Bug > Components: modules/highlighter >Affects Versions: 8.6 >Reporter: Chris Beer >Assignee: David Smiley >Priority: Major > > I'm seeing a regression the UnifiedHighlighter (observed in Solr 8.6, leading > to a crashed core), likely caused by LUCENE-9376 > ([https://github.com/apache/lucene-solr/commit/8e578b4e51cbab206c31653077ce4a3e3a6879b8#diff-f545e503a21f7331f0706fb89f7c663eR648?)] > [~dsmiley] adds: [the] call to close indexReaderWithTermVecCache but this is > a wrapper IndexReader that is not supposed to be closed. It'll close the > underlying real reader if you do which is nasty as that's the live one, which > thus brings down the core. > This is reproducible with Solr 8.6, a trivial configuration > ([https://gist.github.com/cbeer/6d3191918b39e3e83e80ac48c00de925),] and an > empty index with a request like: > http://127.0.0.1:8983/solr/blacklight-core/select?q=id:[*+TO+*]&hl=true&hl.fl=full_text_search_en+full_text_search_pt&hl.offsetSource=postings_with_term_vectors&hl.method=unified > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on a change in pull request #1701: SOLR-14671: Parsing dynamic ZK config sometimes cause NuberFormatException
janhoy commented on a change in pull request #1701: URL: https://github.com/apache/lucene-solr/pull/1701#discussion_r462128930 ## File path: solr/core/src/java/org/apache/solr/handler/admin/ZookeeperStatusHandler.java ## @@ -112,15 +112,21 @@ public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse rsp) throw .map(h -> h.resolveClientPortAddress() + ":" + h.clientPort) .sorted().collect(Collectors.toList()); List dynamicHosts = zkDynamicConfig.getServers().stream() - .map(h -> h.resolveClientPortAddress() + ":" + h.clientPort) + .map(h -> h.resolveClientPortAddress() + ":" + (h.clientPort != null ? h.clientPort : "2181")) Review comment: Agree, I'll do that change and merge 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy merged pull request #1701: SOLR-14671: Parsing dynamic ZK config sometimes cause NuberFormatException
janhoy merged pull request #1701: URL: https://github.com/apache/lucene-solr/pull/1701 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] cpoerschke opened a new pull request #1705: factor out static LTRQParserPlugin.newLTRScoringQuery(...) method
cpoerschke opened a new pull request #1705: URL: https://github.com/apache/lucene-solr/pull/1705 Currently the `ltr` parser takes a single `model` argument from which an `LTRScoringQuery` object is created. If the parser needs to construct multiple `LTRScoringQuery` objects -- e.g. like in #1571 for https://issues.apache.org/jira/browse/SOLR-14560 -- then a utility method for constructing a single `LTRScoringQuery` object could be helpful. Note that the proposed utility method does not know about the argument name i.e. multiple `LTRScoringQuery` objects could correspond to * multiple `model` arguments, or * one `original_model` argument plus one or more `model` arguments, or * some other combination of argument names. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on a change in pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
janhoy commented on a change in pull request #1694:
URL: https://github.com/apache/lucene-solr/pull/1694#discussion_r462323818
##
File path: solr/solrj/src/java/org/apache/solr/cluster/api/SolrNode.java
##
@@ -0,0 +1,39 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cluster.api;
+
+import org.apache.solr.common.util.SimpleMap;
+
+/** A read only view of a Solr node */
+public interface SolrNode {
+
+ /** The node name */
+ String name();
+
+ /**Base http url for this node
+ *
+ * @param isV2 if true gives the /api endpoint , else /solr endpoint
+ */
+ String baseUrl(boolean isV2);
Review comment:
Instead of boolean isV2, what about an Enum, that could then evolve?
##
File path: solr/solrj/src/java/org/apache/solr/cluster/api/Config.java
##
@@ -0,0 +1,40 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cluster.api;
+
+import java.io.InputStream;
+import java.util.Set;
+import java.util.function.Consumer;
+
+import org.apache.solr.common.SolrException;
+
+public interface Config {
+
+ String name();
+
+ /**set of files in the config */
Review comment:
General : Please format Javadocs properly with text starting on line 2
and capital letter, even if it takes more lines.
##
File path: solr/solrj/src/java/org/apache/solr/cluster/api/Config.java
##
@@ -0,0 +1,40 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cluster.api;
+
+import java.io.InputStream;
+import java.util.Set;
+import java.util.function.Consumer;
+
+import org.apache.solr.common.SolrException;
+
+public interface Config {
Review comment:
Use `ConfigSet` instead? `Config` is s overloaded.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14660) Migrating HDFS into a package
[
https://issues.apache.org/jira/browse/SOLR-14660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167449#comment-17167449
]
Istvan Farkas commented on SOLR-14660:
--
I'm working on the HDFS package. As discussed with [~ichattopadhyaya], the
first step of the plan is to move the HDFS code to a module that builds as a
separate jar file and remove the direct HDFS references from the core.
Loading the DirectoryFactory from a separate jar should already be possible.
Loading it from a package requires the jira [~noble.paul] is working on.
I found the following reference points to hdfs:
- CheckHdfsIndex - standalone utility
- HdfsBackupRepository - used from solr.xml
- HdfsDirectoryFactory (from solrconfig.xml), also referenced by the
HdfsBackupRepository, CheckHdfsIndex
- HdfsUpdateLog (invoked from UpdateHandler, // if (dirFactory instanceof
HdfsDirectoryFactory)
- BlockDirectory also references hdfs directory
So far I moved the HDFS-related code and tests to a contrib module and created
gradle build for it and also removed the references from core to HDFS.
The BlockDirectory reference was an instanceof check:
{code}
private long getFileModified(String name) throws IOException {
if (in instanceof FSDirectory) {
File directory = ((FSDirectory) in).getDirectory().toFile();
File file = new File(directory, name);
if (!file.exists()) {
throw new FileNotFoundException("File [" + name + "] not found");
}
return file.lastModified();
} else if (in instanceof HdfsDirectory) {
return ((HdfsDirectory) in).fileModified(name);
} else {
throw new UnsupportedOperationException();
}
}
{code}
I added the getLastModified to the base class and the implementations to
FSDirectory and HdfsDirectory.
Also the updatehandler had some direct references to the HdfsDirectory, I
removed those.
At the unit test level, the tests which are supposed to test Hadoop-level
operations like hadoop authentication are also referencing the HDFS code, it
will need some additional work to clean up those.
I will work on stabilizing this as a separate jar and then sync up with
[~ichattopadhyaya] and [~noble.paul] on making this a package.
> Migrating HDFS into a package
> -
>
> Key: SOLR-14660
> URL: https://issues.apache.org/jira/browse/SOLR-14660
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>
> Following up on the deprecation of HDFS (SOLR-14021), we need to work on
> isolating it away from Solr core and making a package for this. This issue is
> to track the efforts for that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9424) Have a warning comment for AttributeSource.captureState
[
https://issues.apache.org/jira/browse/LUCENE-9424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167454#comment-17167454
]
Haoyu Zhai commented on LUCENE-9424:
[~mikemccand] Thank you!
> Have a warning comment for AttributeSource.captureState
> ---
>
> Key: LUCENE-9424
> URL: https://issues.apache.org/jira/browse/LUCENE-9424
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/javadocs
>Reporter: Haoyu Zhai
>Priority: Trivial
> Fix For: master (9.0), 8.7
>
> Attachments: LUCENE-9424.patch
>
>
> {{AttributeSource.captureState}} is a powerful method that can be used to
> store and (later on) restore the current state, but it comes with a cost of
> copying all attributes in this source and sometimes can be a big cost if
> called multiple times.
> We could probably add a warning to indicate this cost, as this method is
> encapsulated quite well and sometimes people who use it won't be aware of the
> cost.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14660) Migrating HDFS into a package
[ https://issues.apache.org/jira/browse/SOLR-14660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167457#comment-17167457 ] Aroop commented on SOLR-14660: -- [~warper] this is a great start. I have a few questions regarding the codebase for the hdfs backup/restore, these as you many know are collection apis. And it uses HdfsBackupRepository bindings which you found being configured via solr.xml (optionally for those who need it). Have you foreseen any disruption to that call due to this move? I am assuming the collection api handler for that call will now need to use a different import for the new path ? > Migrating HDFS into a package > - > > Key: SOLR-14660 > URL: https://issues.apache.org/jira/browse/SOLR-14660 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > > Following up on the deprecation of HDFS (SOLR-14021), we need to work on > isolating it away from Solr core and making a package for this. This issue is > to track the efforts for that. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9443) "IndexReader is closed" regression in highlighter
[ https://issues.apache.org/jira/browse/LUCENE-9443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167523#comment-17167523 ] ASF subversion and git services commented on LUCENE-9443: - Commit 7d5b61797397fd785c8cc33b2367038d89ace5a9 in lucene-solr's branch refs/heads/master from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7d5b617 ] LUCENE-9443: UnifiedHighlighter shouldn't close reader (#1706) A regression from 8.6. Don't close the underlying IndexReader. > "IndexReader is closed" regression in highlighter > - > > Key: LUCENE-9443 > URL: https://issues.apache.org/jira/browse/LUCENE-9443 > Project: Lucene - Core > Issue Type: Bug > Components: modules/highlighter >Affects Versions: 8.6 >Reporter: Chris Beer >Assignee: David Smiley >Priority: Major > > I'm seeing a regression the UnifiedHighlighter (observed in Solr 8.6, leading > to a crashed core), likely caused by LUCENE-9376 > ([https://github.com/apache/lucene-solr/commit/8e578b4e51cbab206c31653077ce4a3e3a6879b8#diff-f545e503a21f7331f0706fb89f7c663eR648?)] > [~dsmiley] adds: [the] call to close indexReaderWithTermVecCache but this is > a wrapper IndexReader that is not supposed to be closed. It'll close the > underlying real reader if you do which is nasty as that's the live one, which > thus brings down the core. > This is reproducible with Solr 8.6, a trivial configuration > ([https://gist.github.com/cbeer/6d3191918b39e3e83e80ac48c00de925),] and an > empty index with a request like: > http://127.0.0.1:8983/solr/blacklight-core/select?q=id:[*+TO+*]&hl=true&hl.fl=full_text_search_en+full_text_search_pt&hl.offsetSource=postings_with_term_vectors&hl.method=unified > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9443) "IndexReader is closed" regression in highlighter
[ https://issues.apache.org/jira/browse/LUCENE-9443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167522#comment-17167522 ] ASF subversion and git services commented on LUCENE-9443: - Commit 7d5b61797397fd785c8cc33b2367038d89ace5a9 in lucene-solr's branch refs/heads/master from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7d5b617 ] LUCENE-9443: UnifiedHighlighter shouldn't close reader (#1706) A regression from 8.6. Don't close the underlying IndexReader. > "IndexReader is closed" regression in highlighter > - > > Key: LUCENE-9443 > URL: https://issues.apache.org/jira/browse/LUCENE-9443 > Project: Lucene - Core > Issue Type: Bug > Components: modules/highlighter >Affects Versions: 8.6 >Reporter: Chris Beer >Assignee: David Smiley >Priority: Major > > I'm seeing a regression the UnifiedHighlighter (observed in Solr 8.6, leading > to a crashed core), likely caused by LUCENE-9376 > ([https://github.com/apache/lucene-solr/commit/8e578b4e51cbab206c31653077ce4a3e3a6879b8#diff-f545e503a21f7331f0706fb89f7c663eR648?)] > [~dsmiley] adds: [the] call to close indexReaderWithTermVecCache but this is > a wrapper IndexReader that is not supposed to be closed. It'll close the > underlying real reader if you do which is nasty as that's the live one, which > thus brings down the core. > This is reproducible with Solr 8.6, a trivial configuration > ([https://gist.github.com/cbeer/6d3191918b39e3e83e80ac48c00de925),] and an > empty index with a request like: > http://127.0.0.1:8983/solr/blacklight-core/select?q=id:[*+TO+*]&hl=true&hl.fl=full_text_search_en+full_text_search_pt&hl.offsetSource=postings_with_term_vectors&hl.method=unified > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9443) "IndexReader is closed" regression in highlighter
[ https://issues.apache.org/jira/browse/LUCENE-9443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167524#comment-17167524 ] ASF subversion and git services commented on LUCENE-9443: - Commit 4c6032ebe85f792a221f9e313293c17b90382c51 in lucene-solr's branch refs/heads/branch_8_6 from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4c6032e ] LUCENE-9443: UnifiedHighlighter shouldn't close reader (#1706) A regression from 8.6. Don't close the underlying IndexReader. (cherry picked from commit 7d5b61797397fd785c8cc33b2367038d89ace5a9) > "IndexReader is closed" regression in highlighter > - > > Key: LUCENE-9443 > URL: https://issues.apache.org/jira/browse/LUCENE-9443 > Project: Lucene - Core > Issue Type: Bug > Components: modules/highlighter >Affects Versions: 8.6 >Reporter: Chris Beer >Assignee: David Smiley >Priority: Major > > I'm seeing a regression the UnifiedHighlighter (observed in Solr 8.6, leading > to a crashed core), likely caused by LUCENE-9376 > ([https://github.com/apache/lucene-solr/commit/8e578b4e51cbab206c31653077ce4a3e3a6879b8#diff-f545e503a21f7331f0706fb89f7c663eR648?)] > [~dsmiley] adds: [the] call to close indexReaderWithTermVecCache but this is > a wrapper IndexReader that is not supposed to be closed. It'll close the > underlying real reader if you do which is nasty as that's the live one, which > thus brings down the core. > This is reproducible with Solr 8.6, a trivial configuration > ([https://gist.github.com/cbeer/6d3191918b39e3e83e80ac48c00de925),] and an > empty index with a request like: > http://127.0.0.1:8983/solr/blacklight-core/select?q=id:[*+TO+*]&hl=true&hl.fl=full_text_search_en+full_text_search_pt&hl.offsetSource=postings_with_term_vectors&hl.method=unified > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9443) "IndexReader is closed" regression in highlighter
[ https://issues.apache.org/jira/browse/LUCENE-9443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved LUCENE-9443. -- Fix Version/s: 8.6.1 Resolution: Fixed Thanks for the fast bug report with pointer to the problem, Chris! > "IndexReader is closed" regression in highlighter > - > > Key: LUCENE-9443 > URL: https://issues.apache.org/jira/browse/LUCENE-9443 > Project: Lucene - Core > Issue Type: Bug > Components: modules/highlighter >Affects Versions: 8.6 >Reporter: Chris Beer >Assignee: David Smiley >Priority: Major > Fix For: 8.6.1 > > > I'm seeing a regression the UnifiedHighlighter (observed in Solr 8.6, leading > to a crashed core), likely caused by LUCENE-9376 > ([https://github.com/apache/lucene-solr/commit/8e578b4e51cbab206c31653077ce4a3e3a6879b8#diff-f545e503a21f7331f0706fb89f7c663eR648?)] > [~dsmiley] adds: [the] call to close indexReaderWithTermVecCache but this is > a wrapper IndexReader that is not supposed to be closed. It'll close the > underlying real reader if you do which is nasty as that's the live one, which > thus brings down the core. > This is reproducible with Solr 8.6, a trivial configuration > ([https://gist.github.com/cbeer/6d3191918b39e3e83e80ac48c00de925),] and an > empty index with a request like: > http://127.0.0.1:8983/solr/blacklight-core/select?q=id:[*+TO+*]&hl=true&hl.fl=full_text_search_en+full_text_search_pt&hl.offsetSource=postings_with_term_vectors&hl.method=unified > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-12845) Add a default cluster policy
[
https://issues.apache.org/jira/browse/SOLR-12845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman updated SOLR-12845:
--
Fix Version/s: 8.6.1
> Add a default cluster policy
>
>
> Key: SOLR-12845
> URL: https://issues.apache.org/jira/browse/SOLR-12845
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.6, 8.6.1
>
> Attachments: SOLR-12845.patch, SOLR-12845.patch, Screen Shot
> 2020-07-27 at 10.57.33 AM.png, Screenshot from 2020-07-18 21-07-34.png
>
>
> [~varunthacker] commented on SOLR-12739:
> bq. We should also ship with some default policies - "Don't allow more than
> one replica of a shard on the same JVM" , "Distribute cores across the
> cluster evenly" , "Distribute replicas per collection across the nodes"
> This issue is about adding these defaults. I propose the following as default
> cluster policy:
> {code}
> # Each shard cannot have more than one replica on the same node if possible
> {"replica": "<2", "shard": "#EACH", "node": "#ANY", "strict":false}
> # Each collections replicas should be equally distributed amongst nodes
> {"replica": "#EQUAL", "node": "#ANY", "strict":false}
> # All cores should be equally distributed amongst nodes
> {"cores": "#EQUAL", "node": "#ANY", "strict":false}
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12845) Add a default cluster policy
[
https://issues.apache.org/jira/browse/SOLR-12845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman resolved SOLR-12845.
---
Resolution: Abandoned (was: Fixed)
The default cluster policy has been removed in 8.6.1
> Add a default cluster policy
>
>
> Key: SOLR-12845
> URL: https://issues.apache.org/jira/browse/SOLR-12845
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.6.1, 8.6
>
> Attachments: SOLR-12845.patch, SOLR-12845.patch, Screen Shot
> 2020-07-27 at 10.57.33 AM.png, Screenshot from 2020-07-18 21-07-34.png
>
>
> [~varunthacker] commented on SOLR-12739:
> bq. We should also ship with some default policies - "Don't allow more than
> one replica of a shard on the same JVM" , "Distribute cores across the
> cluster evenly" , "Distribute replicas per collection across the nodes"
> This issue is about adding these defaults. I propose the following as default
> cluster policy:
> {code}
> # Each shard cannot have more than one replica on the same node if possible
> {"replica": "<2", "shard": "#EACH", "node": "#ANY", "strict":false}
> # Each collections replicas should be equally distributed amongst nodes
> {"replica": "#EQUAL", "node": "#ANY", "strict":false}
> # All cores should be equally distributed amongst nodes
> {"cores": "#EQUAL", "node": "#ANY", "strict":false}
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-8362) Add docValues support for TextField
[ https://issues.apache.org/jira/browse/SOLR-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167640#comment-17167640 ] David Smiley commented on SOLR-8362: Hey [~hossman] I want to ensure you noticed [~mgibney]'s comment above since I think you've put tons of thought into this years ago -- SOLR-11917 and I think Michael has some similar ideas (poly field). bq. Regarding the (minimal) Lucene changes: in order to support docValues on post-analysis terms, I know it would be possible to do post-analysis docValues entirely in Solr, by "pre-analyzing" in createFields(...), collecting tokens and buffering each into a separate *DocValuesField instance. But it seemed so straightforward (and general-purpose useful?) to do this in Lucene that I went that route initially. If there's interest in pursuing that approach, it could spin off into a separate Lucene issue. Please do file a Lucene issue for that! That reminds me of ideas I was kicking around when building the UnifiedHighlighter wherein I was considering alternatives to term vectors for getting the set of analyzed terms per document. TVs probably make the most sense but it'd be cool to consider a DocValue based option. Even better would be if the main term dictionary supported ordinals (e.g. BlockTreeOrdsPostingsFormat) and there could be a special DV impl that pointed back into a term dictionary instead of duplicating the same dictionary. That would be a huge space savings. > Add docValues support for TextField > --- > > Key: SOLR-8362 > URL: https://issues.apache.org/jira/browse/SOLR-8362 > Project: Solr > Issue Type: Improvement >Reporter: Chris M. Hostetter >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > At the last lucene/solr revolution, Toke asked a question about why TextField > doesn't support docValues. The short answer is because no one ever added it, > but the longer answer was because we would have to think through carefully > the _intent_ of supporting docValues for a "tokenized" field like TextField, > and how to support various conflicting usecases where they could be handy. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
