[jira] [Commented] (SOLR-13972) Insecure Solr should generate startup warning
[ https://issues.apache.org/jira/browse/SOLR-13972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176096#comment-17176096 ] Jan Høydahl commented on SOLR-13972: I think the technically correct way is to open a new Jira to fix the regression, otherwise people will be confused with Jira numbers being reused in CHANGES and it will not be clear which Solr version has a working version? > Insecure Solr should generate startup warning > - > > Key: SOLR-13972 > URL: https://issues.apache.org/jira/browse/SOLR-13972 > Project: Solr > Issue Type: Bug >Reporter: Ishan Chattopadhyaya >Assignee: Jason Gerlowski >Priority: Critical > Fix For: master (9.0), 8.4 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Warning to the effect of, start Solr with: "solr auth enable -credentials > solr:foo -blockUnknown true” (or some other way to achieve the same effect) > if you want to expose this Solr instance directly to users. Maybe the link to > the ref guide discussing all this might be in good measure here. -- 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-13998) Add thread safety annotation to classes
[ https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176102#comment-17176102 ] Marcus Eagan commented on SOLR-13998: - [~anshum] can you link to the branch Mark shared? > Add thread safety annotation to classes > --- > > Key: SOLR-13998 > URL: https://issues.apache.org/jira/browse/SOLR-13998 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0), 8.4 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add annotations that can be used to mark classes as thread safe / single > threaded in Solr. -- 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-13998) Add thread safety annotation to classes
[ https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176101#comment-17176101 ] Marcus Eagan commented on SOLR-13998: - [~anshum] that makes sense. I didn't realized it was cherry picked from his branch. Adding that context into the PR comments before merging might help people to understand the rationale and give them a place to look to contribute. I'll be sure to add it in future classes because I have recently written a single threaded class. If I knew about this, I would have used it. In any event, I am happy it's there if it useful for others. > Add thread safety annotation to classes > --- > > Key: SOLR-13998 > URL: https://issues.apache.org/jira/browse/SOLR-13998 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0), 8.4 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add annotations that can be used to mark classes as thread safe / single > threaded in Solr. -- 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 opened a new pull request #1743: Gradual naming convention enforcement.
dweiss opened a new pull request #1743: URL: https://github.com/apache/lucene-solr/pull/1743 LUCENE-8626. Here's how you can do it in a progressive, incremental way: make an exception list for existing suites not following the convention, but enforce it on anything new. 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] (LUCENE-8626) standardise test class naming
[ https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176109#comment-17176109 ] Dawid Weiss commented on LUCENE-8626: - Pushed a PR for consideration on how this can be done incrementally (but enforced for anything added from now on). > standardise test class naming > - > > Key: LUCENE-8626 > URL: https://issues.apache.org/jira/browse/LUCENE-8626 > Project: Lucene - Core > Issue Type: Test >Reporter: Christine Poerschke >Priority: Major > Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, > SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch > > > This was mentioned and proposed on the dev mailing list. Starting this ticket > here to start to make it happen? > History: This ticket was created as > https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got > JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket. -- 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-8626) standardise test class naming
[ https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176113#comment-17176113 ] Dawid Weiss commented on LUCENE-8626: - As for the convention itself, I'm myself more of a suffix-style kind of guy (so that prefix class searches work for both the class and its test in any environment). I'll follow what's agreed upon though. > standardise test class naming > - > > Key: LUCENE-8626 > URL: https://issues.apache.org/jira/browse/LUCENE-8626 > Project: Lucene - Core > Issue Type: Test >Reporter: Christine Poerschke >Priority: Major > Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, > SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch > > > This was mentioned and proposed on the dev mailing list. Starting this ticket > here to start to make it happen? > History: This ticket was created as > https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got > JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket. -- 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] mocobeta commented on pull request #1742: Standalone distribution assembly for Luke
mocobeta commented on pull request #1742: URL: https://github.com/apache/lucene-solr/pull/1742#issuecomment-672691181 Thanks, it works very well for me! I added dependencies on all analysis modules and suggester. When I run `./gradlew :lucene:luke:run`, I got this error and then figured out that `-Dant.home` property is needed (also Ant must be installed on the machine beforehand) to run the task. ``` Execution failed for task ':lucene:luke:run'. > Execute failed: java.io.IOException: Cannot locate antRun script: Property 'ant.home' not found ``` We are dropping ant build, and the `assemble` task works as an alternative to `ant run` (to me), do we need this task at all...? 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] dweiss commented on pull request #1742: Standalone distribution assembly for Luke
dweiss commented on pull request #1742: URL: https://github.com/apache/lucene-solr/pull/1742#issuecomment-672693199 I'd add those dependencies to 'standalone' configuration, not implementation - so that the implementation configuration is indeed minimal? As for the launcher: this is caused by 'vmlauncher: false'. If you set it to true then it'll work but you'd need to know exact path to 'java' - which you can get from Gradle's VM API. Can you try to figure it out? We can leave that 'run' task for Uwe. :) 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 commented on pull request #1742: Standalone distribution assembly for Luke
mocobeta commented on pull request #1742: URL: https://github.com/apache/lucene-solr/pull/1742#issuecomment-672701544 > I'd add those dependencies to 'standalone' configuration, not implementation I moved them. Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. 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] (LUCENE-9439) Matches API should enumerate hit fields that have no positions (no iterator)
[
https://issues.apache.org/jira/browse/LUCENE-9439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176127#comment-17176127
]
Dawid Weiss commented on LUCENE-9439:
-
Let me know once you take a peek at it, Alan. No rush.
> Matches API should enumerate hit fields that have no positions (no iterator)
>
>
> Key: LUCENE-9439
> URL: https://issues.apache.org/jira/browse/LUCENE-9439
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Attachments: LUCENE-9439.patch, matchhighlighter.patch
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> I have been fiddling with Matches API and it's great. There is one corner
> case that doesn't work for me though -- queries that affect fields without
> positions return {{MatchesUtil.MATCH_WITH_NO_TERMS}} but this constant is
> problematic as it doesn't carry the field name that caused it (returns null).
> The associated fromSubMatches combines all these constants into one (or
> swallows them) which is another problem.
> I think it would be more consistent if MATCH_WITH_NO_TERMS was replaced with
> a true match (carrying field name) returning an empty iterator (or a constant
> "empty" iterator NO_TERMS).
> I have a very compelling use case: I wrote an "auto-highlighter" that runs on
> top of Matches API and automatically picks up query-relevant fields and
> snippets. Everything works beautifully except for cases where fields are
> searchable but don't have any positions (token-like fields).
> I can work on a patch but wanted to reach out first - [~romseygeek]?
--
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-14731) Make use of @SolrSingleThreaded Implementation
Marcus Eagan created SOLR-14731:
---
Summary: Make use of @SolrSingleThreaded Implementation
Key: SOLR-14731
URL: https://issues.apache.org/jira/browse/SOLR-14731
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Environment: {color:red}colored text{color}
Reporter: Marcus Eagan
This change may viewed as minor today, but making a habit of this annotation
should prove very beneficial in the long run when I forget things that I worked
on 3 years ago, 3 years from now.
This is my first attempt to leverage [~anshum]'s work from:
https://issues.apache.org/jira/browse/SOLR-13998
[~anshum] please let me know if I am screwing something up! :) and thanks for
adding this a while back.
--
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-14731) Make use of @SolrSingleThreaded Implementation
[
https://issues.apache.org/jira/browse/SOLR-14731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176145#comment-17176145
]
Marcus Eagan commented on SOLR-14731:
-
this is an annotation to denote that this class is single-threaded.
> Make use of @SolrSingleThreaded Implementation
> ---
>
> Key: SOLR-14731
> URL: https://issues.apache.org/jira/browse/SOLR-14731
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Environment: {color:red}colored text{color}
>Reporter: Marcus Eagan
>Priority: Major
>
> This change may viewed as minor today, but making a habit of this annotation
> should prove very beneficial in the long run when I forget things that I
> worked on 3 years ago, 3 years from now.
> This is my first attempt to leverage [~anshum]'s work from:
> https://issues.apache.org/jira/browse/SOLR-13998
> [~anshum] please let me know if I am screwing something up! :) and thanks for
> adding this a while back.
--
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] mocobeta commented on pull request #1742: Standalone distribution assembly for Luke
mocobeta commented on pull request #1742: URL: https://github.com/apache/lucene-solr/pull/1742#issuecomment-672713515 > As for the launcher: this is caused by 'vmlauncher: false'. If you set it to true then it'll work but you'd need to know exact path to 'java' - which you can get from Gradle's VM API. Can you try to figure it out? With setting 'vmlauncher' to true, the launcher seems to work for me. I didn't need any other changes or configuration... am I missing something? 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] atris commented on a change in pull request #1737: SOLR-14615: Implement CPU Utilization Based Circuit Breaker
atris commented on a change in pull request #1737:
URL: https://github.com/apache/lucene-solr/pull/1737#discussion_r469081264
##
File path: solr/core/src/java/org/apache/solr/core/SolrConfig.java
##
@@ -811,10 +818,18 @@ private void initLibs(SolrResourceLoader loader, boolean
isConfigsetTrusted) {
loader.reloadLuceneSPI();
}
- private void validateMemoryBreakerThreshold() {
+ private void validateCircuitBreakerThresholds() {
if (useCircuitBreakers) {
- if (memoryCircuitBreakerThresholdPct > 95 ||
memoryCircuitBreakerThresholdPct < 50) {
-throw new IllegalArgumentException("Valid value range of
memoryCircuitBreakerThresholdPct is 50 - 95");
+ if (isMemoryCircuitBreakerEnabled) {
+if (memoryCircuitBreakerThresholdPct > 95 ||
memoryCircuitBreakerThresholdPct < 50) {
+ throw new IllegalArgumentException("Valid value range of
memoryCircuitBreakerThresholdPct is 50 - 95");
+}
+ }
+
+ if (isCpuCircuitBreakerEnabled) {
+if (cpuCircuitBreakerThresholdPct > 95 ||
cpuCircuitBreakerThresholdPct < 40) {
+ throw new IllegalArgumentException("Valid value range for
cpuCircuitBreakerThresholdPct is 40 - 95");
Review comment:
Scratch that, this is a value that can exceed 100 as well. Removed the
top ceiling on the value here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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 #1744: SOLR-14731: Add SingleThreaded Annotation to Class
MarcusSorealheis opened a new pull request #1744: URL: https://github.com/apache/lucene-solr/pull/1744 # Description Makes use of @anshumg and @markrmiller's single threaded annotation so that it is more obvious to maintainers. # Solution adds it. # Tests Tests do not change for this one. # 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
[jira] [Commented] (SOLR-14712) Standardize RPC calls in Solr
[
https://issues.apache.org/jira/browse/SOLR-14712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176146#comment-17176146
]
Ishan Chattopadhyaya commented on SOLR-14712:
-
Let us name this better. "RPC" feels suspiciously close to GRPC or C style
executing functions remotely on other machines.
> Standardize RPC calls in Solr
> -
>
> Key: SOLR-14712
> URL: https://issues.apache.org/jira/browse/SOLR-14712
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> We should have a standard mechanism to make a request to the right
> replica/node across solr code.
> This RPC mechanism assumes that
> * The RPC mechanism is HTTP
> * It is aware of all collections,shards & their topology etc
> * it knows how to route a request to the correct core
> This is agnostic of wire level formats ,Solr documents etc. That is a layer
> above this.
> Anyone can use their own JSON parser or any other RPC wire level format on
> top of this
> for example a code like this
> {code}
> private void invokeOverseerOp(String electionNode, String op) {
> ModifiableSolrParams params = new ModifiableSolrParams();
> ShardHandler shardHandler = shardHandlerFactory.getShardHandler();
> params.set(CoreAdminParams.ACTION, CoreAdminAction.OVERSEEROP.toString());
> params.set("op", op);
> params.set("qt", adminPath);
> params.set("electionNode", electionNode);
> ShardRequest sreq = new ShardRequest();
> sreq.purpose = 1;
> String replica =
> zkStateReader.getBaseUrlForNodeName(LeaderElector.getNodeName(electionNode));
> sreq.shards = new String[]\{replica};
> sreq.actualShards = sreq.shards;
> sreq.params = params;
> shardHandler.submit(sreq, replica, sreq.params);
> shardHandler.takeCompletedOrError();
> }
> {code}
> will be replaced with
> {code}
> private void invokeOverseerOp(String electionNode, String op) {
> RpcFactory factory = null;
> factory.createCallRouter()
> .toNode(electionNode)
> .createHttpRpc()
> .withMethod(SolrRequest.METHOD.GET)
> .addParam(CoreAdminParams.ACTION,
> CoreAdminAction.OVERSEEROP.toString())
> .addParam("op", op)
> .addParam("electionNode", electionNode)
> .addParam(ShardParams.SHARDS_PURPOSE, 1)
> .withV1Path(adminPath)
> .invoke();
> }
> {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
[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1744: SOLR-14731: Add SingleThreaded Annotation to Class
MarcusSorealheis commented on pull request #1744: URL: https://github.com/apache/lucene-solr/pull/1744#issuecomment-672714337 simple PR here, will the package masters @chatman and @noblepaul please take a look, as well as @anshumg. I'll use this annotation going forward as applicable. Thanks for adding it! ☺️ 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] dweiss commented on pull request #1742: Standalone distribution assembly for Luke
dweiss commented on pull request #1742: URL: https://github.com/apache/lucene-solr/pull/1742#issuecomment-672715512 I think the VM launcher doesn't respect search path on all environments. You have to provide an explicit path to the binary you're willing to launch. This is how it used to work, at least. I'm sure it'll be more consistent and reliable to have an explicit path to java. Something like this should retrieve it: JavaInstallationRegistry registry = project.extensions.getByType(JavaInstallationRegistry) JavaInstallation currentJvm = registry.installationForCurrentVirtualMachine.get() return currentJvm.jdk.get().javadocExecutable.asFile 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-14712) Standardize RPC calls in Solr
[
https://issues.apache.org/jira/browse/SOLR-14712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176151#comment-17176151
]
Noble Paul commented on SOLR-14712:
---
I shall just name it` RemoteCall` instead of RPC which is "Remote Procedure
Call"
> Standardize RPC calls in Solr
> -
>
> Key: SOLR-14712
> URL: https://issues.apache.org/jira/browse/SOLR-14712
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> We should have a standard mechanism to make a request to the right
> replica/node across solr code.
> This RPC mechanism assumes that
> * The RPC mechanism is HTTP
> * It is aware of all collections,shards & their topology etc
> * it knows how to route a request to the correct core
> This is agnostic of wire level formats ,Solr documents etc. That is a layer
> above this.
> Anyone can use their own JSON parser or any other RPC wire level format on
> top of this
> for example a code like this
> {code}
> private void invokeOverseerOp(String electionNode, String op) {
> ModifiableSolrParams params = new ModifiableSolrParams();
> ShardHandler shardHandler = shardHandlerFactory.getShardHandler();
> params.set(CoreAdminParams.ACTION, CoreAdminAction.OVERSEEROP.toString());
> params.set("op", op);
> params.set("qt", adminPath);
> params.set("electionNode", electionNode);
> ShardRequest sreq = new ShardRequest();
> sreq.purpose = 1;
> String replica =
> zkStateReader.getBaseUrlForNodeName(LeaderElector.getNodeName(electionNode));
> sreq.shards = new String[]\{replica};
> sreq.actualShards = sreq.shards;
> sreq.params = params;
> shardHandler.submit(sreq, replica, sreq.params);
> shardHandler.takeCompletedOrError();
> }
> {code}
> will be replaced with
> {code}
> private void invokeOverseerOp(String electionNode, String op) {
> RpcFactory factory = null;
> factory.createCallRouter()
> .toNode(electionNode)
> .createHttpRpc()
> .withMethod(SolrRequest.METHOD.GET)
> .addParam(CoreAdminParams.ACTION,
> CoreAdminAction.OVERSEEROP.toString())
> .addParam("op", op)
> .addParam("electionNode", electionNode)
> .addParam(ShardParams.SHARDS_PURPOSE, 1)
> .withV1Path(adminPath)
> .invoke();
> }
> {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-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176162#comment-17176162 ] Jan Høydahl commented on SOLR-14497: What's the status here? Last I recall was [~dsmiley] working on an email to send to committers in order to prepare the board resolution? Are we still aiming to setup the Solr PMC before 9.0 so that Lucene can release 9.0 alone, followed by an independent Solr 9.0 release? > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Se > [https://cwiki.apache.org/confluence/display/LUCENE/Solr+TLP+needed+changes] > for a tabular view of possible changes. > *TODO*: Add sub tasks. > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # Determine how to split web site > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- 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-9457) Why is Kuromoji tokenization throughput bimodal?
[
https://issues.apache.org/jira/browse/LUCENE-9457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176164#comment-17176164
]
Dawid Weiss commented on LUCENE-9457:
-
bq. It could be hotspot noise maybe?
Could be. Or it could be something else running in the background? It'd be good
to somehow monitor background CPU activity while these benchmarks are being
made. I'm not much of a sysop to help out here though.
> Why is Kuromoji tokenization throughput bimodal?
>
>
> Key: LUCENE-9457
> URL: https://issues.apache.org/jira/browse/LUCENE-9457
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Priority: Major
>
> With the recent accidental regression of Japanese (Kuromoji) tokenization
> throughput due to exciting FST optimizations, we [added new nightly Lucene
> benchmarks|https://github.com/mikemccand/luceneutil/issues/64] to measure
> tokenization throughput for {{JapaneseTokenizer}}:
> [https://home.apache.org/~mikemccand/lucenebench/analyzers.html]
> It has already been running for ~5-6 weeks now! But for some reason, it
> looks bi-modal? "Normally" it is ~.45 M tokens/sec, but for two data points
> it dropped down to ~.33 M tokens/sec, which is odd. It could be hotspot
> noise maybe? But would be good to get to the root cause and fix it if
> possible.
> Hotspot noise that randomly steals ~27% of your tokenization throughput is no
> good!!
> Or does anyone have any other ideas of what could be bi-modal in Kuromoji? I
> don't think [this performance
> test|https://github.com/mikemccand/luceneutil/blob/master/src/main/perf/TestAnalyzerPerf.java]
> has any randomness in it...
--
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-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176165#comment-17176165 ] Dawid Weiss commented on SOLR-14497: > Are we still aiming to setup the Solr PMC before 9.0 so that Lucene can > release 9.0 alone, followed by an independent Solr 9.0 release? I'm +1 for this but it'll require some build-system work to get the stand-alone source distribution ready (among other things). This is fun stuff to do but it takes me away from my regular job and there's not much time left. I'll see what I can do to push it forward though. > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Se > [https://cwiki.apache.org/confluence/display/LUCENE/Solr+TLP+needed+changes] > for a tabular view of possible changes. > *TODO*: Add sub tasks. > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # Determine how to split web site > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- 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] MarcusSorealheis commented on a change in pull request #1737: SOLR-14615: Implement CPU Utilization Based Circuit Breaker
MarcusSorealheis commented on a change in pull request #1737:
URL: https://github.com/apache/lucene-solr/pull/1737#discussion_r469104910
##
File path: solr/core/src/java/org/apache/solr/core/SolrConfig.java
##
@@ -811,10 +818,18 @@ private void initLibs(SolrResourceLoader loader, boolean
isConfigsetTrusted) {
loader.reloadLuceneSPI();
}
- private void validateMemoryBreakerThreshold() {
+ private void validateCircuitBreakerThresholds() {
if (useCircuitBreakers) {
- if (memoryCircuitBreakerThresholdPct > 95 ||
memoryCircuitBreakerThresholdPct < 50) {
-throw new IllegalArgumentException("Valid value range of
memoryCircuitBreakerThresholdPct is 50 - 95");
+ if (isMemoryCircuitBreakerEnabled) {
+if (memoryCircuitBreakerThresholdPct > 95 ||
memoryCircuitBreakerThresholdPct < 50) {
+ throw new IllegalArgumentException("Valid value range of
memoryCircuitBreakerThresholdPct is 50 - 95");
+}
+ }
+
+ if (isCpuCircuitBreakerEnabled) {
+if (cpuCircuitBreakerThresholdPct > 95 ||
cpuCircuitBreakerThresholdPct < 40) {
+ throw new IllegalArgumentException("Valid value range for
cpuCircuitBreakerThresholdPct is 40 - 95");
Review comment:
It typically doesn't go past 450 unless you have an issue. I would still
keep it bounded at some measure @atris
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] (LUCENE-8776) Start offset going backwards has a legitimate purpose
[
https://issues.apache.org/jira/browse/LUCENE-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176184#comment-17176184
]
Simon Willnauer commented on LUCENE-8776:
-
I think preventing negative offsets is more than just allowing people to pay
the price of 5 bytes per negative offset. There are many more things than
compression based on this behavior. Just a few that come to my mind right away:
* Correctness verification of indices, if we see a negative offset the index
must be broken.
* Catch broken analyzers early
* have clear bounds of what an offset can be and in what direction it can
grow. This helps tons if you want to implement future features that can rely on
this behavior.
{quote}
So if we just add a simple mechanism to instruct Lucene which DocConsumer to
use, then all could be happy and not have to resort to dirty hacks or forks.
The most efficient impl will be the default, yet will allow us us - dirty
bastards - shoot ourselves in foot if we so desire. SOLR as well as
ElasticSearch devs might not mind having the option in the future - it can come
in handy. Wouldn't that be wonderful? Well, wonderful certainly not, just
useful... could I do it?
{quote}
if you feel like you wanna implement this, go ahead. I am sure there will be
more issues like Check Index will not work anymore etc. There might be future
features you will break with doing this. But again it's all open source, nobody
forces you to upgrade or use the code we package directly. You can download the
source and modify it that' is all up to you.
We as a community need to make decisions that sometimes don't work for
everybody. We have a great responsibility with a project like Lucene being used
in an unbelievable wide range of applications and that sometimes means to add
restrictions. We don't take this easily, it's almost always a hard decisions.
Having offsets going forward only will be a win for a large majority and that's
why we keep on having this restrictions. I am totally sorry for you struggle.
Talking about extending DocConsumer, I am torn it should be a extension point.
I know that there is an implementation that uses it out there but if I could
pick I'd remove this extension since it's, as you say, way to hard to get it
right.
> Start offset going backwards has a legitimate purpose
> -
>
> Key: LUCENE-8776
> URL: https://issues.apache.org/jira/browse/LUCENE-8776
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 7.6
>Reporter: Ram Venkat
>Priority: Major
>
> Here is the use case where startOffset can go backwards:
> Say there is a line "Organic light-emitting-diode glows", and I want to run
> span queries and highlight them properly.
> During index time, light-emitting-diode is split into three words, which
> allows me to search for 'light', 'emitting' and 'diode' individually. The
> three words occupy adjacent positions in the index, as 'light' adjacent to
> 'emitting' and 'light' at a distance of two words from 'diode' need to match
> this word. So, the order of words after splitting are: Organic, light,
> emitting, diode, glows.
> But, I also want to search for 'organic' being adjacent to
> 'light-emitting-diode' or 'light-emitting-diode' being adjacent to 'glows'.
> The way I solved this was to also generate 'light-emitting-diode' at two
> positions: (a) In the same position as 'light' and (b) in the same position
> as 'glows', like below:
> ||organic||light||emitting||diode||glows||
> | |light-emitting-diode| |light-emitting-diode| |
> |0|1|2|3|4|
> The positions of the two 'light-emitting-diode' are 1 and 3, but the offsets
> are obviously the same. This works beautifully in Lucene 5.x in both
> searching and highlighting with span queries.
> But when I try this in Lucene 7.6, it hits the condition "Offsets must not go
> backwards" at DefaultIndexingChain:818. This IllegalArgumentException is
> being thrown without any comments on why this check is needed. As I explained
> above, startOffset going backwards is perfectly valid, to deal with word
> splitting and span operations on these specialized use cases. On the other
> hand, it is not clear what value is added by this check and which highlighter
> code is affected by offsets going backwards. This same check is done at
> BaseTokenStreamTestCase:245.
> I see others talk about how this check found bugs in WordDelimiter etc. but
> it also prevents legitimate use cases. Can this check be removed?
--
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.apa
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17176215#comment-17176215
]
Mark Robert Miller commented on SOLR-14636:
---
Getting so close even with so much yet to wrap up. My entire childhood was
spent telling people I was just waiting until I actually could stop myself from
just fooling around and try at something instead of just giving off the
appearance. This is the first. This is my try. It’s almost always one too many
plates in the air, but I see a good landing spot just over there.
> 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, solr-ref-branch.gif
>
>
> 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-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:comment-tabpanel&focusedCommentId=17176226#comment-17176226
]
Mark Robert Miller commented on SOLR-14636:
---
I’d also like to thank those that made this possible. Those that got me started
again on this attempt because they are not willing to accept the status quo,
and my sponsors, who crazily gave me enough rope to hang myself and half the
town to get this done.
> 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, solr-ref-branch.gif
>
>
> 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-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176229#comment-17176229 ] Jan Høydahl commented on SOLR-14497: Yea, lots of things to do there. I wonder if it makes sense to start working on the split in a branch, or if there is just too much other stuff going on in master these days? Should probably get rid of ant in master and a few other things before starting a branch.. Do you want to lay out somewhere, which steps are needed to do the actual git and build transition? Perhaps in [https://cwiki.apache.org/confluence/display/LUCENE/Solr+TLP+needed+changes] ? Hopefully you'll get plenty of assistance! > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Se > [https://cwiki.apache.org/confluence/display/LUCENE/Solr+TLP+needed+changes] > for a tabular view of possible changes. > *TODO*: Add sub tasks. > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # Determine how to split web site > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- 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-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:comment-tabpanel&focusedCommentId=17176231#comment-17176231
]
Markus Jelsma commented on SOLR-14636:
--
Hi [~markrmiller] , as curious as a was, i tried to compile it and load it with
custom libs, cores and data to see how it performs. Unfortunately i cannot get
it to run, nor does the internal ZK listen to upconfig calls.
This is what i get from the logs:
{code:java}
2020-08-12 10:09:42.999 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Found
0 core definitions underneath /home/markus/temp/lucene-solr/solr/server/solr
2020-08-12 10:09:42.999 INFO (main) [ ] o.a.s.c.ParWork No work collected to
submit
2020-08-12 10:10:18.169 WARN (solr-jetty-thread-1-thread-12) [ ]
o.e.j.s.HttpChannel /solr/ => java.lang.NullPointerException
at org.apache.solr.servlet.SolrQoSFilter.doFilter(SolrQoSFilter.java:63)
java.lang.NullPointerException: null
at
org.apache.solr.servlet.SolrQoSFilter.doFilter(SolrQoSFilter.java:63)
~[solr-core-9.0.0-SNAPSHOT.jar:9.0.0-SNAPSHOT
750d69b54614ed1cfa895c455da3efd7f0d71cc3 - markus - 2020-08-12 12:05:18]
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
~[jetty-servlet-9.4.27.v20200227.jar:9.4.27.v20200227]
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
~[jetty-servlet-9.4.27.v20200227.jar:9.4.27.v20200227]
{code}
My tree is up to date. Any thoughts?
> 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, solr-ref-branch.gif
>
>
> 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-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176236#comment-17176236 ] Dawid Weiss commented on SOLR-14497: Getting rid of ant is very likely a prerequisite since it'll be hard to push things forward without it... Erick filed a Jira issue for that. I have to think about what exact steps are needed myself. But thanks for nagging - it is motivating. :) > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Se > [https://cwiki.apache.org/confluence/display/LUCENE/Solr+TLP+needed+changes] > for a tabular view of possible changes. > *TODO*: Add sub tasks. > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # Determine how to split web site > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- 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-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:comment-tabpanel&focusedCommentId=17176237#comment-17176237
]
Markus Jelsma commented on SOLR-14636:
--
Well, adding a null check there fixes the problem, but the internal ZK is still
not listening. Don't know about that.
> 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, solr-ref-branch.gif
>
>
> 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-13972) Insecure Solr should generate startup warning
[ https://issues.apache.org/jira/browse/SOLR-13972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176242#comment-17176242 ] Jason Gerlowski commented on SOLR-13972: Oh, ok. If that's what we typically do. I think it's confusing either way. The way I look at this bug, it means that the goal of this Jira was never achieved in the first place. 8.4 never had correct error messages here, so why bother preserving the 8.4 fix version here. (i.e. Unless someone digs into the comments here, they'll see that this was working in 8.4 when it wasn't). But I understand the concern about the CHANGES.txt numbers. I'll open a new jira. > Insecure Solr should generate startup warning > - > > Key: SOLR-13972 > URL: https://issues.apache.org/jira/browse/SOLR-13972 > Project: Solr > Issue Type: Bug >Reporter: Ishan Chattopadhyaya >Assignee: Jason Gerlowski >Priority: Critical > Fix For: master (9.0), 8.4 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Warning to the effect of, start Solr with: "solr auth enable -credentials > solr:foo -blockUnknown true” (or some other way to achieve the same effect) > if you want to expose this Solr instance directly to users. Maybe the link to > the ref guide discussing all this might be in good measure here. -- 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-13972) Insecure Solr should generate startup warning
[ https://issues.apache.org/jira/browse/SOLR-13972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski resolved SOLR-13972. > Insecure Solr should generate startup warning > - > > Key: SOLR-13972 > URL: https://issues.apache.org/jira/browse/SOLR-13972 > Project: Solr > Issue Type: Bug >Reporter: Ishan Chattopadhyaya >Assignee: Jason Gerlowski >Priority: Critical > Fix For: master (9.0), 8.4 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Warning to the effect of, start Solr with: "solr auth enable -credentials > solr:foo -blockUnknown true” (or some other way to achieve the same effect) > if you want to expose this Solr instance directly to users. Maybe the link to > the ref guide discussing all this might be in good measure here. -- 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-13412) Make the Lucene Luke module available from a Solr distribution
[ https://issues.apache.org/jira/browse/SOLR-13412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176252#comment-17176252 ] David Eric Pugh commented on SOLR-13412: Thats great [~tomoko], if you write up the getting started guide, I'll happily add Luke to both the ref guide glossary and a link from the existing LukeRequestHandler docs! Maybe we want to have a page in the Ref Guide that is more generally about Lucene indexes, that might point to various resources that a Solr centric person might be interested in. Especially useful once Solr goes TLP > Make the Lucene Luke module available from a Solr distribution > -- > > Key: SOLR-13412 > URL: https://issues.apache.org/jira/browse/SOLR-13412 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13412.patch > > > Now that [~Tomoko Uchida] has put in a great effort to bring Luke into the > project, I think it would be good to be able to access it from a Solr distro. > I want to go to the right place under the Solr install directory and start > Luke up to examine the local indexes. > This ticket is explicitly _not_ about accessing it from the admin UI, Luke is > a stand-alone app that must be invoked on the node that has a Lucene index on > the local filesystem > We need to > * have it included in Solr when running "ant package". > * add some bits to the ref guide on how to invoke > ** Where to invoke it from > ** mention anything that has to be installed. > ** any other "gotchas" someone just installing Solr should be aware of. > * Ant should not be necessary. > * > > I'll assign this to myself to keep track of, but would not be offended in the > least if someone with more knowledge of "ant package" and the like wanted to > take it over ;) > If we can do it 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-14726) Streamline getting started experience
[
https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176253#comment-17176253
]
David Eric Pugh commented on SOLR-14726:
makes sense. I did some reading and found out that cURL now ships in Windows
10! I fired up a VM, and checked with some Windows using colleagues, and they
confirmed that cURL came preinstalled.
> Streamline getting started experience
> -
>
> Key: SOLR-14726
> URL: https://issues.apache.org/jira/browse/SOLR-14726
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Labels: newdev
> Attachments: yasa-http.png
>
>
> The reference guide Solr tutorial is here:
> https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html
> It needs to be simplified and easy to follow. Also, it should reflect our
> best practices, that should also be followed in production. I have following
> suggestions:
> # Make it less verbose. It is too long. On my laptop, it required 35 page
> downs button presses to get to the bottom of the page!
> # First step of the tutorial should be to enable security (basic auth should
> suffice).
> # {{./bin/solr start -e cloud}} <-- All references of -e should be removed.
> # All references of {{bin/solr post}} to be replaced with {{curl}}
> # Convert all {{bin/solr create}} references to curl of collection creation
> commands
> # Add docker based startup instructions.
> # Create a Jupyter Notebook version of the entire tutorial, make it so that
> it can be easily executed from Google Colaboratory. Here's an example:
> https://twitter.com/TheSearchStack/status/1289703715981496320
> # Provide downloadable Postman and Insomnia files so that the same tutorial
> can be executed from those tools. Except for starting Solr, all other steps
> should be possible to be carried out from those tools.
> # Use V2 APIs everywhere in the tutorial
> # Remove all example modes, sample data (films, tech products etc.),
> configsets from Solr's distribution (instead let the examples refer to them
> from github)
> # Remove the post tool from Solr, curl should suffice.
--
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-14677) DIH doesnt close DataSource when import encounters errors
[ https://issues.apache.org/jira/browse/SOLR-14677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176256#comment-17176256 ] David Eric Pugh commented on SOLR-14677: Unfortunately, that makes sense to me on the plugin repo. In a perfect world, the plugin repo owner will see these commits and pull them over proactively. > DIH doesnt close DataSource when import encounters errors > - > > Key: SOLR-14677 > URL: https://issues.apache.org/jira/browse/SOLR-14677 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Affects Versions: 7.5, master (9.0) >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Minor > Attachments: error-solr.log, no-error-solr.log > > Time Spent: 10m > Remaining Estimate: 0h > > DIH imports don't close DataSource's (which can hold db connections, etc.) in > all cases. Specifically, if an import runs into an unexpected error > forwarding processed docs to other nodes, it will neglect to close the > DataSource's when it finishes. > This problem goes back to at least 7.5. This is partially mitigated in older > versions of some DataSource implementations (e.g. JdbcDataSource) by means of > a "finalize" hook which invokes "close()" when the DataSource object is > garbage-collected. In practice, this means that resources might be held open > longer than necessary but will be closed within a few seconds or minutes by > GC. This only helps JdbcDataSource though - all other DataSource impl's risk > leaking resources. > In master/9.0, which requires a minimum of Java 11 and doesn't have the > finalize-hook, the connections are never cleaned up when an error is > encountered during DIH. DIH will likely be removed for the 9.0 release, but > if it isn't this bug should be fixed. -- 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-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176255#comment-17176255 ] Jan Høydahl commented on SOLR-14497: I created two sub tasks here already, which is probably a good place to detail the independent tasks. I guess the split could happen at any point in time, even before an 8.x release, but once the split has started it triggers a lot of work before the next release can be done, so it needs to be planned carefully. > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Se > [https://cwiki.apache.org/confluence/display/LUCENE/Solr+TLP+needed+changes] > for a tabular view of possible changes. > *TODO*: Add sub tasks. > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # Determine how to split web site > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- 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-14726) Streamline getting started experience
[
https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176267#comment-17176267
]
Jan Høydahl commented on SOLR-14726:
Don't have your hopes too high there. Last time I tried cURL in Windows
(PowerShell), it was nothing more than an alias to some built-in Cmdlet. It
worked for the plain GET URL case, but once you try POST, PUT, headers and
other cmdline args it fails big time. I believe it is a failure of MS to alias
'curl' (a Trademark) to something that is far from curl. But I don't use Win,
so who knows, perhaps they included the real thing lately?
> Streamline getting started experience
> -
>
> Key: SOLR-14726
> URL: https://issues.apache.org/jira/browse/SOLR-14726
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Labels: newdev
> Attachments: yasa-http.png
>
>
> The reference guide Solr tutorial is here:
> https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html
> It needs to be simplified and easy to follow. Also, it should reflect our
> best practices, that should also be followed in production. I have following
> suggestions:
> # Make it less verbose. It is too long. On my laptop, it required 35 page
> downs button presses to get to the bottom of the page!
> # First step of the tutorial should be to enable security (basic auth should
> suffice).
> # {{./bin/solr start -e cloud}} <-- All references of -e should be removed.
> # All references of {{bin/solr post}} to be replaced with {{curl}}
> # Convert all {{bin/solr create}} references to curl of collection creation
> commands
> # Add docker based startup instructions.
> # Create a Jupyter Notebook version of the entire tutorial, make it so that
> it can be easily executed from Google Colaboratory. Here's an example:
> https://twitter.com/TheSearchStack/status/1289703715981496320
> # Provide downloadable Postman and Insomnia files so that the same tutorial
> can be executed from those tools. Except for starting Solr, all other steps
> should be possible to be carried out from those tools.
> # Use V2 APIs everywhere in the tutorial
> # Remove all example modes, sample data (films, tech products etc.),
> configsets from Solr's distribution (instead let the examples refer to them
> from github)
> # Remove the post tool from Solr, curl should suffice.
--
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-8776) Start offset going backwards has a legitimate purpose
[ https://issues.apache.org/jira/browse/LUCENE-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176273#comment-17176273 ] Dawid Weiss commented on LUCENE-8776: - I just wanted to chip in a lateral idea that crossed my mind - if these offsets are required only for highlighting then one could get around the problem stated in the description of this issue by indexing positions only and retrieving hit position offsets using matches API. These positions would have to be retrieved using a *different* attribute than offsets attribute but that attribute could go backwards... Yes, it would require re-parsing the content for highlighting but it would also be a clean and elegant solution to the original problem without the need to hack Lucene internals. There is a fresh set of components that could be used for building such a highlighter on top of matches API in LUCENE-9439. All that would be needed is a specific implementation of position-to-offsets strategy that retrieves those arbitrary offsets for a token's position. I think this could work. Just a thought. > Start offset going backwards has a legitimate purpose > - > > Key: LUCENE-8776 > URL: https://issues.apache.org/jira/browse/LUCENE-8776 > Project: Lucene - Core > Issue Type: Bug > Components: core/search >Affects Versions: 7.6 >Reporter: Ram Venkat >Priority: Major > > Here is the use case where startOffset can go backwards: > Say there is a line "Organic light-emitting-diode glows", and I want to run > span queries and highlight them properly. > During index time, light-emitting-diode is split into three words, which > allows me to search for 'light', 'emitting' and 'diode' individually. The > three words occupy adjacent positions in the index, as 'light' adjacent to > 'emitting' and 'light' at a distance of two words from 'diode' need to match > this word. So, the order of words after splitting are: Organic, light, > emitting, diode, glows. > But, I also want to search for 'organic' being adjacent to > 'light-emitting-diode' or 'light-emitting-diode' being adjacent to 'glows'. > The way I solved this was to also generate 'light-emitting-diode' at two > positions: (a) In the same position as 'light' and (b) in the same position > as 'glows', like below: > ||organic||light||emitting||diode||glows|| > | |light-emitting-diode| |light-emitting-diode| | > |0|1|2|3|4| > The positions of the two 'light-emitting-diode' are 1 and 3, but the offsets > are obviously the same. This works beautifully in Lucene 5.x in both > searching and highlighting with span queries. > But when I try this in Lucene 7.6, it hits the condition "Offsets must not go > backwards" at DefaultIndexingChain:818. This IllegalArgumentException is > being thrown without any comments on why this check is needed. As I explained > above, startOffset going backwards is perfectly valid, to deal with word > splitting and span operations on these specialized use cases. On the other > hand, it is not clear what value is added by this check and which highlighter > code is affected by offsets going backwards. This same check is done at > BaseTokenStreamTestCase:245. > I see others talk about how this check found bugs in WordDelimiter etc. but > it also prevents legitimate use cases. Can this check be removed? -- 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-14470) Add streaming expressions to /export handler
[
https://issues.apache.org/jira/browse/SOLR-14470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176282#comment-17176282
]
ASF subversion and git services commented on SOLR-14470:
Commit a5543dfb5112d12b9616f2d09cd07e9805b177de in lucene-solr's branch
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a5543df ]
SOLR-14470: Fix test failures by reducing the randomness of test data.
> Add streaming expressions to /export handler
>
>
> Key: SOLR-14470
> URL: https://issues.apache.org/jira/browse/SOLR-14470
> Project: Solr
> Issue Type: Improvement
> Components: Export Writer, streaming expressions
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Many streaming scenarios would greatly benefit from the ability to perform
> partial rollups (or other transformations) as early as possible, in order to
> minimize the amount of data that has to be sent from shards to the
> aggregating node.
> This can be implemented as a subset of streaming expressions that process the
> data directly inside each local {{ExportHandler}} and outputs only the
> records from the resulting stream.
> Conceptually it would be similar to the way Hadoop {{Combiner}} works. As is
> the case with {{Combiner}}, because the input data is processed in batches
> there would be no guarantee that only 1 record per unique sort values would
> be emitted - in fact, in most cases multiple partial aggregations would be
> emitted. Still, in many scenarios this would allow reducing the amount of
> data to be sent by several orders of magnitude.
--
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-14726) Streamline getting started experience
[
https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176286#comment-17176286
]
Ishan Chattopadhyaya commented on SOLR-14726:
-
If someone wants to take forward the non controversial pieces discussed here,
please create sub-tasks to this JIRA and proceed.
> Streamline getting started experience
> -
>
> Key: SOLR-14726
> URL: https://issues.apache.org/jira/browse/SOLR-14726
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Labels: newdev
> Attachments: yasa-http.png
>
>
> The reference guide Solr tutorial is here:
> https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html
> It needs to be simplified and easy to follow. Also, it should reflect our
> best practices, that should also be followed in production. I have following
> suggestions:
> # Make it less verbose. It is too long. On my laptop, it required 35 page
> downs button presses to get to the bottom of the page!
> # First step of the tutorial should be to enable security (basic auth should
> suffice).
> # {{./bin/solr start -e cloud}} <-- All references of -e should be removed.
> # All references of {{bin/solr post}} to be replaced with {{curl}}
> # Convert all {{bin/solr create}} references to curl of collection creation
> commands
> # Add docker based startup instructions.
> # Create a Jupyter Notebook version of the entire tutorial, make it so that
> it can be easily executed from Google Colaboratory. Here's an example:
> https://twitter.com/TheSearchStack/status/1289703715981496320
> # Provide downloadable Postman and Insomnia files so that the same tutorial
> can be executed from those tools. Except for starting Solr, all other steps
> should be possible to be carried out from those tools.
> # Use V2 APIs everywhere in the tutorial
> # Remove all example modes, sample data (films, tech products etc.),
> configsets from Solr's distribution (instead let the examples refer to them
> from github)
> # Remove the post tool from Solr, curl should suffice.
--
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-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:comment-tabpanel&focusedCommentId=17176290#comment-17176290
]
Ishan Chattopadhyaya commented on SOLR-14636:
-
[~markus17], I run this branch using an external ZK, via docker. There is some
issue with the embedded ZK, but that isn't a show stopper at the moment.
> 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, solr-ref-branch.gif
>
>
> 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-14504) ZkController LiveNodesListener has NullPointerException in startup race
[
https://issues.apache.org/jira/browse/SOLR-14504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176291#comment-17176291
]
Colvin Cowie commented on SOLR-14504:
-
[~ab] this did make it into 8.6 right? But it's not been closed/
> ZkController LiveNodesListener has NullPointerException in startup race
> ---
>
> Key: SOLR-14504
> URL: https://issues.apache.org/jira/browse/SOLR-14504
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3,
> 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14504.patch
>
>
> If a NODELOST event happens before the cloudManager is initialized then a
> NullPointerException will occur on this line
> [https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
> {code:java}
> byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
> cloudManager.getTimeSource().getEpochTimeNs())); {code}
> Rather than accessing cloudManager directly, getSolrCloudManager() should be
> called.
>
> This happens very rarely, but if it happens it will stop Solr starting,
> result in "CoreContainer is either not initialized or shutting down". Snippet
> from 8.3.1
> {noformat}
> 2020-05-19 03:44:40.241 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.245 INFO (zkConnectionManagerCallback-11-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.245 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.359 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.361 INFO (zkConnectionManagerCallback-13-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.361 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.417 INFO (main) [ ] o.a.s.c.c.ZkStateReader Updated
> live nodes from ZooKeeper... (0) -> (1)
> 2020-05-19
> 03:44:56.606 INFO (zkCallback-12-thread-2) [ ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) ->
> (0)
> 2020-05-19 03:44:56.614 ERROR (main) [ ]
> o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
> property and the logs
> 2020-05-19 03:44:56.639 ERROR (main) [ ] o.a.s.c.SolrCore
> null:java.lang.NullPointerException
> at
> org.apache.solr.cloud.ZkController.lambda$registerLiveNodesListener$10(ZkController.java:1020)
> at
> org.apache.solr.common.cloud.ZkStateReader.registerLiveNodesListener(ZkStateReader.java:880)
> at
> org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)
> at org.apache.solr.cloud.ZkController.init(ZkController.java:917)
> at org.apache.solr.cloud.ZkController.(ZkController.java:473)
> at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:115)
> at
> org.apache.solr.core.CoreContainer.load(CoreContainer.java:631){noformat}
>
>
--
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-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:comment-tabpanel&focusedCommentId=17176293#comment-17176293
]
Ishan Chattopadhyaya commented on SOLR-14636:
-
bq. I’d also like to thank those that made this possible. Those that got me
started again on this attempt because they are not willing to accept the status
quo, and my sponsors, who crazily gave me enough rope to hang myself and half
the town to get this done.
I would like to sincerely thank you for this effort. This is 10x better than
the best Solr has ever seen before. I am extremely excited about this future
and looking forward to start developing on this and taking it towards a
release. Users and developers alike will find it extremely stable, performant
and reliable to work with this branch of Solr!
> 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, solr-ref-branch.gif
>
>
> 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] (LUCENE-9455) ExitableTermsEnum (in ExitableDirectoryReader) should sample next()
[ https://issues.apache.org/jira/browse/LUCENE-9455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176313#comment-17176313 ] Adrien Grand commented on LUCENE-9455: -- +1 > ExitableTermsEnum (in ExitableDirectoryReader) should sample next() > --- > > Key: LUCENE-9455 > URL: https://issues.apache.org/jira/browse/LUCENE-9455 > Project: Lucene - Core > Issue Type: Improvement > Components: core/other >Reporter: David Smiley >Priority: Major > > ExitableTermsEnum calls "checkAndThrow" on *every* call to next(). This is > too expensive; it should sample. I observed ElasticSearch uses the same > approach; I think Lucene would benefit from this: > https://github.com/elastic/elasticsearch/blob/4af4eb99e18fdaadac879b1223e986227dd2ee71/server/src/main/java/org/elasticsearch/search/internal/ExitableDirectoryReader.java#L151 > CC [~jimczi] -- 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] jpountz commented on a change in pull request #1731: LUCENE-9451 Sort.rewrite does not always return this when unchanged
jpountz commented on a change in pull request #1731:
URL: https://github.com/apache/lucene-solr/pull/1731#discussion_r469225237
##
File path: lucene/core/src/java/org/apache/lucene/search/Sort.java
##
@@ -177,12 +177,12 @@ public Sort rewrite(IndexSearcher searcher) throws
IOException {
SortField[] rewrittenSortFields = new SortField[fields.length];
for (int i = 0; i < fields.length; i++) {
rewrittenSortFields[i] = fields[i].rewrite(searcher);
- if (fields[i] != rewrittenSortFields[i]) {
+ if (! fields[i].equals(rewrittenSortFields[i])) {
Review comment:
this should remain a reference equality check
##
File path: lucene/core/src/test/org/apache/lucene/search/TestSort.java
##
@@ -878,4 +878,22 @@ public void testMultiSort() throws IOException {
ir.close();
dir.close();
}
+
+ public void testRewrite() throws IOException {
+try (Directory dir = newDirectory()) {
+ RandomIndexWriter writer = new RandomIndexWriter(random(), dir);
+ IndexSearcher searcher = newSearcher(writer.getReader());
+ writer.close();
+
+ LongValuesSource longSource = LongValuesSource.constant(1L);
+ Sort sort = new Sort(longSource.getSortField(false));
+
+ assertSame(sort, sort.rewrite(searcher));
+
+ DoubleValuesSource doubleSource = DoubleValuesSource.constant(1.0);
+ sort = new Sort(doubleSource.getSortField(false));
+
+ assertSame(sort, sort.rewrite(searcher));
+}
+ }
Review comment:
This test looks like it belongs to
TestDoubleValuesSource/TestLongValuesSource more than it belongs to TestSort?
##
File path: lucene/core/src/java/org/apache/lucene/search/DoubleValuesSource.java
##
@@ -456,13 +456,16 @@ public String toString() {
@Override
public SortField rewrite(IndexSearcher searcher) throws IOException {
- DoubleValuesSortField rewritten = new
DoubleValuesSortField(producer.rewrite(searcher), reverse);
+ DoubleValuesSource rewrittenSource = producer.rewrite(searcher);
+ if (rewrittenSource == producer) {
Review comment:
Reference equality is the right check.
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] (LUCENE-9455) ExitableTermsEnum (in ExitableDirectoryReader) should sample next()
[ https://issues.apache.org/jira/browse/LUCENE-9455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176316#comment-17176316 ] Bruno Roustant commented on LUCENE-9455: +1 > ExitableTermsEnum (in ExitableDirectoryReader) should sample next() > --- > > Key: LUCENE-9455 > URL: https://issues.apache.org/jira/browse/LUCENE-9455 > Project: Lucene - Core > Issue Type: Improvement > Components: core/other >Reporter: David Smiley >Priority: Major > > ExitableTermsEnum calls "checkAndThrow" on *every* call to next(). This is > too expensive; it should sample. I observed ElasticSearch uses the same > approach; I think Lucene would benefit from this: > https://github.com/elastic/elasticsearch/blob/4af4eb99e18fdaadac879b1223e986227dd2ee71/server/src/main/java/org/elasticsearch/search/internal/ExitableDirectoryReader.java#L151 > CC [~jimczi] -- 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-9451) Sort.rewrite doesn't always return this when unchanged
[
https://issues.apache.org/jira/browse/LUCENE-9451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176317#comment-17176317
]
Adrien Grand commented on LUCENE-9451:
--
If there's agreement that the contract of Sort#rewrite should be the same as
Query#rewrite, I think we should fix IndexSearcher to call Sort#rewrite in a
loop until it returns the same instance, which would have caught this.
> Sort.rewrite doesn't always return this when unchanged
> --
>
> Key: LUCENE-9451
> URL: https://issues.apache.org/jira/browse/LUCENE-9451
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 8.7
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Sort.rewrite doesn't always return {{this}} as advertised in the Javadoc even
> if the underlying fields are unchanged. This is because the comparison uses
> reference equality.
> There are two solutions we can do here, 1) switch from reference equality to
> object equality, and 2) fix some of the underlying sort fields to not create
> unnecessary objects.
> cc: [~jpountz] [~romseygeek]
--
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] mocobeta commented on pull request #1742: Standalone distribution assembly for Luke
mocobeta commented on pull request #1742: URL: https://github.com/apache/lucene-solr/pull/1742#issuecomment-672850897 Ah, I got it. Thanks again for your patience. https://github.com/apache/lucene-solr/pull/1742/commits/243979a3eb42ba027e1fa9c82745c65a88d386cd works for 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
[jira] [Commented] (SOLR-13350) Explore collector managers for multi-threaded search
[ https://issues.apache.org/jira/browse/SOLR-13350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176319#comment-17176319 ] Ishan Chattopadhyaya commented on SOLR-13350: - As per an offline conversation with [~atris], I requested him to revive this issue and work on taking it to the completion. I will help him as he does so. Thanks for your help, [~atris]. FYI, Atri has optimized this feature at Lucene level and has intimate knowledge of how it works internally. > Explore collector managers for multi-threaded search > > > Key: SOLR-13350 > URL: https://issues.apache.org/jira/browse/SOLR-13350 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-13350.patch, SOLR-13350.patch, SOLR-13350.patch > > Time Spent: 2h 20m > Remaining Estimate: 0h > > AFAICT, SolrIndexSearcher can be used only to search all the segments of an > index in series. However, using CollectorManagers, segments can be searched > concurrently and result in reduced latency. Opening this issue to explore the > effectiveness of using CollectorManagers in SolrIndexSearcher from latency > and throughput perspective. -- 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-8626) standardise test class naming
[ https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176323#comment-17176323 ] Erick Erickson commented on LUCENE-8626: +100 to David's comment. We should refrain from wholesale changes like this until we figure out what to do with Mark's reference impl. I've been hoping that all the files I changed with the SuppressWarnings won't be a problem in that regard, I didn't realize at the time that the reference impl diverge this long > standardise test class naming > - > > Key: LUCENE-8626 > URL: https://issues.apache.org/jira/browse/LUCENE-8626 > Project: Lucene - Core > Issue Type: Test >Reporter: Christine Poerschke >Priority: Major > Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, > SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch > > > This was mentioned and proposed on the dev mailing list. Starting this ticket > here to start to make it happen? > History: This ticket was created as > https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got > JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket. -- 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] gerlowskija commented on pull request #1713: SOLR-14703 Edismax parser replaces whitespace characters with spaces
gerlowskija commented on pull request #1713: URL: https://github.com/apache/lucene-solr/pull/1713#issuecomment-672878162 Hey @yuriy-b-koval , it took me awhile to understand it, but I spent some time brushing up on edismax and am confident enough to say this LGTM now. That said - one thing that might still be nice here would be to have unit tests on ExtendedDismaxQParser.splitIntoClauses itself. That'd give us more targeted validation of your change here. It'd also give us a regression barrier in case someone breaks the logic in splitIntoClauses somewhere down the road. Would you be willing to tackle those tests? (Or did you already try to write tests at that level and run into some roadblock or other?) They're not strictly necessary, but I'd like one of us to give them a shot if we can before merging. 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 #1726: SOLR-14722: timeAllowed should track from req creation
dsmiley commented on a change in pull request #1726:
URL: https://github.com/apache/lucene-solr/pull/1726#discussion_r469268231
##
File path: solr/core/src/java/org/apache/solr/search/SolrQueryTimeoutImpl.java
##
@@ -67,8 +69,21 @@ public boolean shouldExit() {
}
/**
- * Method to set the time at which the timeOut should happen.
- * @param timeAllowed set the time at which this thread should timeout.
+ * Sets or clears the time allowed based on how much time remains from the
start of the request plus the configured
+ * {@link CommonParams#TIME_ALLOWED}.
+ */
+ public static void set(SolrQueryRequest req) {
+long timeAllowed = req.getParams().getLong(CommonParams.TIME_ALLOWED, -1L);
+if (timeAllowed >= 0L) {
Review comment:
MLT Handler was the exception it's used *way* less often than
SearchHandler and so I ignored that. I agree that the docs are wrong; I will
update them.
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] dweiss merged pull request #1742: Standalone distribution assembly for Luke
dweiss merged pull request #1742: URL: https://github.com/apache/lucene-solr/pull/1742 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] (LUCENE-9459) "Getting Started" guide for Luke
[ https://issues.apache.org/jira/browse/LUCENE-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176367#comment-17176367 ] Cassandra Targett commented on LUCENE-9459: --- Just a note here since the Solr Ref Guide came up in the issue that spawned this (SOLR-13412), if you write the getting started guide in AsciiDoc format (.adoc), then it will be tremendously simple for the Ref Guide to just consume it entirely. Meaning, instead of asking readers of the Ref Guide to go somewhere else to find out how to use Luke, they can learn about it right there and we still have a single file to maintain. This would be true after the project repo split also. It's just an option, though - I know Lucene doesn't have a process today for converting .adoc files to HTML for the website or javadocs, so it might be too complicated and a link from the Ref Guide (when we get there) is easier. That would be fine, I just wanted to throw it out there as an option. > "Getting Started" guide for Luke > - > > Key: LUCENE-9459 > URL: https://issues.apache.org/jira/browse/LUCENE-9459 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/luke >Reporter: Tomoko Uchida >Priority: Major > Labels: newdev > > While Luke has been very popular, widely accepted tool to Lucene users > (including Solr and Elasticsearch users) for 10+ years, it lacks good > documentation and/or user guide. Although Luke is a GUI tool that describes > itself, it's not good for new users. > The lack of documentation is partly due to my laziness though, there is some > inherent difficulty of explaining such low-level tool; if you don't know > Lucene you don't understand Luke's capability or usefulness, if you once > understand Lucene at some level, it's obvious to you and no explanation is > needed. :) > Nonetheless, it would be great if we have "Getting Started" documentation for > Luke on our web site for new users/devs. > We may be able to have a Markdown file with some screenshots and usage > descriptions, then convert it to HTML by Gradle task, so that we can publish > it with whole API documentation. -- 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] cpoerschke opened a new pull request #1745: Append MultiCollectorTest to TestMultiCollector.
cpoerschke opened a new pull request #1745: URL: https://github.com/apache/lucene-solr/pull/1745 As part of https://issues.apache.org/jira/browse/LUCENE-8626 I noticed that `MultiCollector` has two tests. This pull request proposes to unify them into one test. 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 merged pull request #867: SOLR-13751: add BooleanSimilarityFactory
cpoerschke merged pull request #867: URL: https://github.com/apache/lucene-solr/pull/867 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-13751) Add BooleanSimilarityFactory to Solr
[ https://issues.apache.org/jira/browse/SOLR-13751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176373#comment-17176373 ] ASF subversion and git services commented on SOLR-13751: Commit e72a0d66c666dec7d69f1f2e15306957656d2e70 in lucene-solr's branch refs/heads/master from andywebb1975 [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e72a0d6 ] SOLR-13751: add BooleanSimilarityFactory (#867) > Add BooleanSimilarityFactory to Solr > > > Key: SOLR-13751 > URL: https://issues.apache.org/jira/browse/SOLR-13751 > Project: Solr > Issue Type: New Feature >Reporter: Andy Webb >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > Solr doesn't expose Lucene's BooleanSimilarity (ref LUCENE-5867) so it's not > available for use in situations where BM25/TDF-IF are not useful. (Fields > using this similarity will likely also set omitNorms and > omitTermFreqAndPositions to true.) > Our use case is ngram-driven suggestions, where the frequency of occurrence > of a particular sequence of characters is not something users would expect to > be taken into account when ordering suggestions. > > Here's my PR: [https://github.com/apache/lucene-solr/pull/867] (I'm at > Activate if anyone would like to talk this through in person.) -- 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-9448) Make an equivalent to Ant's "run" target for Luke module
[
https://issues.apache.org/jira/browse/LUCENE-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176383#comment-17176383
]
Tomoko Uchida commented on LUCENE-9448:
---
Seeing {{standalonePackage}} task, I started to reconsider about distribution -
would it be natural and understandable that we distribute stand-alone Luke app
(and exclude the luke artifact from Lucene package)? I don't think it should be
related to 9.0.0 release, I'd like to revisit it in the future releases. Just
an idea.
> Make an equivalent to Ant's "run" target for Luke module
>
>
> Key: LUCENE-9448
> URL: https://issues.apache.org/jira/browse/LUCENE-9448
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Tomoko Uchida
>Priority: Minor
> Attachments: LUCENE-9448.patch, LUCENE-9448.patch
>
>
> With Ant build, Luke Swing app can be launched by "ant run" after checking
> out the source code. "ant run" allows developers to immediately see the
> effects of UI changes without creating the whole zip/tgz package (originally,
> it was suggested when integrating Luke to Lucene).
> In Gradle, {{:lucene:luke:run}} task would be easily implemented with
> {{JavaExec}}, I think.
--
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-13751) Add BooleanSimilarityFactory to Solr
[ https://issues.apache.org/jira/browse/SOLR-13751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176385#comment-17176385 ] ASF subversion and git services commented on SOLR-13751: Commit 1145362a248aea6ea56189c10279a23efd3e988a in lucene-solr's branch refs/heads/branch_8x from andywebb1975 [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1145362 ] SOLR-13751: add BooleanSimilarityFactory (#867) > Add BooleanSimilarityFactory to Solr > > > Key: SOLR-13751 > URL: https://issues.apache.org/jira/browse/SOLR-13751 > Project: Solr > Issue Type: New Feature >Reporter: Andy Webb >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > Solr doesn't expose Lucene's BooleanSimilarity (ref LUCENE-5867) so it's not > available for use in situations where BM25/TDF-IF are not useful. (Fields > using this similarity will likely also set omitNorms and > omitTermFreqAndPositions to true.) > Our use case is ngram-driven suggestions, where the frequency of occurrence > of a particular sequence of characters is not something users would expect to > be taken into account when ordering suggestions. > > Here's my PR: [https://github.com/apache/lucene-solr/pull/867] (I'm at > Activate if anyone would like to talk this through in person.) -- 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-13751) Add BooleanSimilarityFactory to Solr
[ https://issues.apache.org/jira/browse/SOLR-13751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-13751: --- Fix Version/s: 8.7 master (9.0) Assignee: Christine Poerschke Resolution: Fixed Status: Resolved (was: Patch Available) Thanks [~andywebb1975]! > Add BooleanSimilarityFactory to Solr > > > Key: SOLR-13751 > URL: https://issues.apache.org/jira/browse/SOLR-13751 > Project: Solr > Issue Type: New Feature >Reporter: Andy Webb >Assignee: Christine Poerschke >Priority: Minor > Fix For: master (9.0), 8.7 > > Time Spent: 40m > Remaining Estimate: 0h > > Solr doesn't expose Lucene's BooleanSimilarity (ref LUCENE-5867) so it's not > available for use in situations where BM25/TDF-IF are not useful. (Fields > using this similarity will likely also set omitNorms and > omitTermFreqAndPositions to true.) > Our use case is ngram-driven suggestions, where the frequency of occurrence > of a particular sequence of characters is not something users would expect to > be taken into account when ordering suggestions. > > Here's my PR: [https://github.com/apache/lucene-solr/pull/867] (I'm at > Activate if anyone would like to talk this through in person.) -- 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-9448) Make an equivalent to Ant's "run" target for Luke module
[
https://issues.apache.org/jira/browse/LUCENE-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176388#comment-17176388
]
Dawid Weiss commented on LUCENE-9448:
-
It is absolutely possible and doable. I think Luke should be part of Lucene
distribution artifacts - whether together or separately, that's an open
question. I'm sure this question will pop up again once we get down to how to
assemble distribution packages from gradle level.
> Make an equivalent to Ant's "run" target for Luke module
>
>
> Key: LUCENE-9448
> URL: https://issues.apache.org/jira/browse/LUCENE-9448
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Tomoko Uchida
>Priority: Minor
> Attachments: LUCENE-9448.patch, LUCENE-9448.patch
>
>
> With Ant build, Luke Swing app can be launched by "ant run" after checking
> out the source code. "ant run" allows developers to immediately see the
> effects of UI changes without creating the whole zip/tgz package (originally,
> it was suggested when integrating Luke to Lucene).
> In Gradle, {{:lucene:luke:run}} task would be easily implemented with
> {{JavaExec}}, I think.
--
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-8626) standardise test class naming
[
https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176393#comment-17176393
]
Christine Poerschke commented on LUCENE-8626:
-
Looking for tests where we currently have both {{TestFooBar.java}} and
{{FooBarTest.java}} present via something like
{code}
(find . -name "*Test.java" ; find . -name "Test*.java") | sed 's/Test//g' |
sort | uniq -c | sort -nr | grep -v 1
{code}
finds 4 matches
{code}
2 ./solr/core/src/test/org/apache/solr/core/DirectoryFactory.java
2 ./solr/core/src/test/org/apache/solr/cloud/ConfigSetsAPI.java
2 ./solr/core/src/test/org/apache/solr/SolrCaseJ4.java
2 ./lucene/core/src/test/org/apache/lucene/search/MultiCollector.java
{code}
and for the {{MultiCollector}} one I've just opened
https://github.com/apache/lucene-solr/pull/1745 PR. Haven't looked yet if/how
the other 3 might be handled.
> standardise test class naming
> -
>
> Key: LUCENE-8626
> URL: https://issues.apache.org/jira/browse/LUCENE-8626
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Christine Poerschke
>Priority: Major
> Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch,
> SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch
>
>
> This was mentioned and proposed on the dev mailing list. Starting this ticket
> here to start to make it happen?
> History: This ticket was created as
> https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got
> JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket.
--
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-9459) "Getting Started" guide for Luke
[
https://issues.apache.org/jira/browse/LUCENE-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176403#comment-17176403
]
Tomoko Uchida commented on LUCENE-9459:
---
Hi [~ctargett],
{quote}instead of asking readers of the Ref Guide to go somewhere else to find
out how to use Luke, they can learn about it right there and we still have a
single file to maintain.
{quote}
good input, thanks! I think we firstly should follow Lucene convention
(Markdown), but we could convert .md file to .adoc file when building
documentation (there may be converter tool, or we may be able to write a simple
tool for that).
> "Getting Started" guide for Luke
> -
>
> Key: LUCENE-9459
> URL: https://issues.apache.org/jira/browse/LUCENE-9459
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/luke
>Reporter: Tomoko Uchida
>Priority: Major
> Labels: newdev
>
> While Luke has been very popular, widely accepted tool to Lucene users
> (including Solr and Elasticsearch users) for 10+ years, it lacks good
> documentation and/or user guide. Although Luke is a GUI tool that describes
> itself, it's not good for new users.
> The lack of documentation is partly due to my laziness though, there is some
> inherent difficulty of explaining such low-level tool; if you don't know
> Lucene you don't understand Luke's capability or usefulness, if you once
> understand Lucene at some level, it's obvious to you and no explanation is
> needed. :)
> Nonetheless, it would be great if we have "Getting Started" documentation for
> Luke on our web site for new users/devs.
> We may be able to have a Markdown file with some screenshots and usage
> descriptions, then convert it to HTML by Gradle task, so that we can publish
> it with whole API documentation.
--
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-13751) Add BooleanSimilarityFactory to Solr
[ https://issues.apache.org/jira/browse/SOLR-13751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176407#comment-17176407 ] Andy Webb commented on SOLR-13751: -- Great, thanks [~cpoerschke]! > Add BooleanSimilarityFactory to Solr > > > Key: SOLR-13751 > URL: https://issues.apache.org/jira/browse/SOLR-13751 > Project: Solr > Issue Type: New Feature >Reporter: Andy Webb >Assignee: Christine Poerschke >Priority: Minor > Fix For: master (9.0), 8.7 > > Time Spent: 40m > Remaining Estimate: 0h > > Solr doesn't expose Lucene's BooleanSimilarity (ref LUCENE-5867) so it's not > available for use in situations where BM25/TDF-IF are not useful. (Fields > using this similarity will likely also set omitNorms and > omitTermFreqAndPositions to true.) > Our use case is ngram-driven suggestions, where the frequency of occurrence > of a particular sequence of characters is not something users would expect to > be taken into account when ordering suggestions. > > Here's my PR: [https://github.com/apache/lucene-solr/pull/867] (I'm at > Activate if anyone would like to talk this through in person.) -- 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-9447) Make BEST_COMPRESSION compress more aggressively?
[ https://issues.apache.org/jira/browse/LUCENE-9447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176411#comment-17176411 ] Adrien Grand commented on LUCENE-9447: -- I collected some data using various block sizes and a preset dict that consists of the first 32kB of the dataset like on LUCENE-6100. The dataset consists of 1M highly compressible doucments whose total uncompressed size is 2.2GB. ||Block size||Preset dict||Stored fields size||Index time||Merge time|| |BEST_SPEED|No|304MB|9s|200ms| |60kB|No|100.6MB|14s|70ms| |60kB|Yes|64.5MB|17s|50ms| |256kB|No|63.8MB|16.5s|40ms| |256kB|Yes|54.7MB|17.5s|40ms| |1MB|No|54.7MB|16s|32ms| |1MB|Yes|52.3MB|16.5s|32ms| Merging is always fast, because in this case we copy the compressed data directly. It looks like the relative inefficiency of the preset dictionary decreases as the block size increases, but I still worry that preset dictionaries would be challenging to integrate while still copying compressed data when merging as we can only do it if blocks use the same dictionary? > Make BEST_COMPRESSION compress more aggressively? > - > > Key: LUCENE-9447 > URL: https://issues.apache.org/jira/browse/LUCENE-9447 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > > The Lucene86 codec supports setting a "Mode" for stored fields compression, > that is either "BEST_SPEED", which translates to blocks of 16kB or 128 > documents (whichever is hit first) compressed with LZ4, or > "BEST_COMPRESSION", which translates to blocks of 60kB or 512 documents > compressed with DEFLATE with default compression level (6). > After looking at indices that spent most disk space on stored fields > recently, I noticed that there was quite some room for improvement by > increasing the block size even further: > ||Block size||Stored fields size|| > |60kB|168412338| > |128kB|130813639| > |256kB|113587009| > |512kB|104776378| > |1MB|100367095| > |2MB|98152464| > |4MB|97034425| > |8MB|96478746| > For this specific dataset, I had 1M documents that each had about 2kB of > stored fields each and quite some redundancy. > This makes me want to look into bumping this block size to maybe 256kB. It > would be interesting to re-do the experiments we did on LUCENE-6100 to see > how this affects the merging speed. That said I don't think it would be > terrible if the merging time increased a bit given that we already offer the > BEST_SPEED option for CPU-savvy users. -- 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] sigram commented on a change in pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface
sigram commented on a change in pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#discussion_r469366732
##
File path:
solr/core/src/java/org/apache/solr/cluster/placement/PlacementPlugin.java
##
@@ -0,0 +1,41 @@
+/*
+ * 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.placement;
+
+/**
+ * Implemented by external plugins to control replica placement and movement
on the search cluster (as well as other things
+ * such as cluster elasticity?) when cluster changes are required (initiated
elsewhere, most likely following a Collection
+ * API call).
+ */
+public interface PlacementPlugin {
Review comment:
I'm strongly against using static variables.
We can either assume that plugins are basically stateless and configured on
the fly, or stateful - and in the latter case they could be re-configurable
(which has its own problems) or not - that is, you have to create a new
instance of the plugin if configuration has changed. In this case there's no
problem with synchronization - the old instance of the plugin completes its
work using the old config.
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 #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface
sigram commented on a change in pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#discussion_r469369547
##
File path: solr/core/src/java/org/apache/solr/cluster/placement/Cluster.java
##
@@ -0,0 +1,53 @@
+/*
+ * 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.placement;
+
+import java.io.IOException;
+import java.util.Optional;
+import java.util.Set;
+
+/**
+ * A representation of the (initial) cluster state, providing information
on which nodes are part of the cluster and a way
+ * to get to more detailed info.
+ *
+ * This instance can also be used as a {@link PropertyValueSource} if
{@link PropertyKey}'s need to be specified with
+ * a global cluster target.
+ */
+public interface Cluster extends PropertyValueSource {
+ /**
+ * @return current set of live nodes. Never null, never empty
(Solr wouldn't call the plugin if empty
+ * since no useful work could then be done).
+ */
+ Set getLiveNodes();
+
+ /**
+ * Returns info about the given collection if one exists. Because it is
not expected for plugins to request info about
+ * a large number of collections, requests can only be made one by one.
+ *
+ * This is also the reason we do not return a {@link java.util.Map} or
{@link Set} of {@link SolrCollection}'s here: it would be
+ * wasteful to fetch all data and fill such a map when plugin code likely
needs info about at most one or two collections.
+ */
+ Optional getCollection(String collectionName) throws
IOException;
+
+ /**
+ * Allows getting all {@link SolrCollection} present in the cluster.
+ *
+ * WARNING: this call might be extremely inefficient on large
clusters. Usage is discouraged.
+ */
+ Set getAllCollections();
Review comment:
Yes, that's the case today, but other parts of Solr suffer from this
problem too, and there are already discussions to move away from one
ClusterState to `Collection getCollectionNames()` + `DocCollection
getCollection(name)`.
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] munendrasn opened a new pull request #1746: Fix syntax warning in smokeTestRelease.py
munendrasn opened a new pull request #1746: URL: https://github.com/apache/lucene-solr/pull/1746 while verifying the 8.6.1 release with the latest python(3.8.5), observed one SyntaxWarning. https://adamj.eu/tech/2020/01/21/why-does-python-3-8-syntaxwarning-for-is-literal/ 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-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=17176456#comment-17176456
]
Willem ter Berg commented on SOLR-11611:
[~jafurrer] you could try using
{code:java}
cd C:\PROGRA~2\Company Name\ProductName Solr\bin
solr start
{code}
PROGRA~1 is an alternative name of Program Files.
PROGRA~2 is an alternative name of Program Files (x86).
Tested on Windows 10 with Solr 8.6.0 with folder structure as described:
{code:java}
C:\PROGRA~2\Company Name\ProductName Solr\bin>solr start
OpenJDK 64-Bit Server VM warning: JVM cannot use large page memory because it
does not have enough privilege to lock pages in memory.
Waiting up to 30 to see Solr running on port 8983
Started Solr server on port 8983. Happy searching!{code}
Note that Windows installations can be configured not to support PROGRA~n. And
some installations may support them but point to another directory.
> 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] (LUCENE-9439) Matches API should enumerate hit fields that have no positions (no iterator)
[
https://issues.apache.org/jira/browse/LUCENE-9439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176468#comment-17176468
]
Alan Woodward commented on LUCENE-9439:
---
This looks fantastic [~dweiss]! We should probably change the issue
description to better describe what you've added (ie a whole new highlighter
impl) - or do you want to split the changes to Matches and the new highlighter
into two separate issues?
One thing that might be nice would be to add something like the test
highlighter into the main code line, as currently you have to do a fair amount
of work to actually use this. But we can do that as a followup - I wouldn't be
surprised if we can build factory methods that more or less replace the
existing highlighters. I also need to think about how we can integrate
submatches into this - it would be great to add the submatches of a span or
interval hit as well as the overall match, and use the latter to build passages
but the former to do actual highlighting.
> Matches API should enumerate hit fields that have no positions (no iterator)
>
>
> Key: LUCENE-9439
> URL: https://issues.apache.org/jira/browse/LUCENE-9439
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Attachments: LUCENE-9439.patch, matchhighlighter.patch
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> I have been fiddling with Matches API and it's great. There is one corner
> case that doesn't work for me though -- queries that affect fields without
> positions return {{MatchesUtil.MATCH_WITH_NO_TERMS}} but this constant is
> problematic as it doesn't carry the field name that caused it (returns null).
> The associated fromSubMatches combines all these constants into one (or
> swallows them) which is another problem.
> I think it would be more consistent if MATCH_WITH_NO_TERMS was replaced with
> a true match (carrying field name) returning an empty iterator (or a constant
> "empty" iterator NO_TERMS).
> I have a very compelling use case: I wrote an "auto-highlighter" that runs on
> top of Matches API and automatically picks up query-relevant fields and
> snippets. Everything works beautifully except for cases where fields are
> searchable but don't have any positions (token-like fields).
> I can work on a patch but wanted to reach out first - [~romseygeek]?
--
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-14733) Mosby Zacharski
Hannah Slaughter Zacharski created SOLR-14733: - Summary: Mosby Zacharski Key: SOLR-14733 URL: https://issues.apache.org/jira/browse/SOLR-14733 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: Hannah Slaughter Zacharski Attachments: 4A042D99-0A9E-49F8-9FAC-97D167F42724.jpeg -- 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-14734) Boone Zacharski
Hannah Slaughter Zacharski created SOLR-14734: - Summary: Boone Zacharski Key: SOLR-14734 URL: https://issues.apache.org/jira/browse/SOLR-14734 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: Hannah Slaughter Zacharski Attachments: A285456C-C5EC-413A-8318-3B56D5607F91.tiff -- 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-14735) Katarzyna Zacharski
Hannah Slaughter Zacharski created SOLR-14735: - Summary: Katarzyna Zacharski Key: SOLR-14735 URL: https://issues.apache.org/jira/browse/SOLR-14735 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: Hannah Slaughter Zacharski Attachments: E8B567B0-8178-4A7F-808B-53C8F12C03F0.jpeg -- 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-14736) Hannah Zacharski
Hannah Slaughter Zacharski created SOLR-14736: - Summary: Hannah Zacharski Key: SOLR-14736 URL: https://issues.apache.org/jira/browse/SOLR-14736 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: Hannah Slaughter Zacharski Attachments: 21603240-8274-454C-A8AF-9E528EDA3152.jpeg -- 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-14737) Michael Zacharski
Hannah Slaughter Zacharski created SOLR-14737: - Summary: Michael Zacharski Key: SOLR-14737 URL: https://issues.apache.org/jira/browse/SOLR-14737 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: Hannah Slaughter Zacharski Attachments: 9412E2D0-85FB-4C45-AC38-EF4466C61C2E.jpeg -- 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-14738) CLONE - Mosby Zacharski
Hannah Slaughter Zacharski created SOLR-14738: - Summary: CLONE - Mosby Zacharski Key: SOLR-14738 URL: https://issues.apache.org/jira/browse/SOLR-14738 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: Hannah Slaughter Zacharski Attachments: 4A042D99-0A9E-49F8-9FAC-97D167F42724.jpeg -- 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-14732) Lena Slaughter
[ https://issues.apache.org/jira/browse/SOLR-14732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hannah Slaughter Zacharski updated SOLR-14732: -- Attachment: 2C39F0B9-5F94-404F-B4D7-1A5CDCCF8721.jpeg Security: Public (was: Private (Security Issue)) > Lena Slaughter > -- > > Key: SOLR-14732 > URL: https://issues.apache.org/jira/browse/SOLR-14732 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hannah Slaughter Zacharski >Priority: Major > Attachments: 2C39F0B9-5F94-404F-B4D7-1A5CDCCF8721.jpeg, > 83F5CCEA-EF2C-412B-AE98-45C9DDB95323.jpeg > > -- 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] [Deleted] (SOLR-14734) Boone Zacharski
[ https://issues.apache.org/jira/browse/SOLR-14734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya deleted SOLR-14734: > Boone Zacharski > --- > > Key: SOLR-14734 > URL: https://issues.apache.org/jira/browse/SOLR-14734 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hannah Slaughter Zacharski >Priority: Major > -- 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] [Deleted] (SOLR-14733) Mosby Zacharski
[ https://issues.apache.org/jira/browse/SOLR-14733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya deleted SOLR-14733: > Mosby Zacharski > --- > > Key: SOLR-14733 > URL: https://issues.apache.org/jira/browse/SOLR-14733 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hannah Slaughter Zacharski >Priority: Major > -- 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-14739) CLONE - Lena Slaughter
Hannah Slaughter Zacharski created SOLR-14739: - Summary: CLONE - Lena Slaughter Key: SOLR-14739 URL: https://issues.apache.org/jira/browse/SOLR-14739 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: Hannah Slaughter Zacharski Attachments: 2C39F0B9-5F94-404F-B4D7-1A5CDCCF8721.jpeg, 83F5CCEA-EF2C-412B-AE98-45C9DDB95323.jpeg -- 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] [Deleted] (SOLR-14735) Katarzyna Zacharski
[ https://issues.apache.org/jira/browse/SOLR-14735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya deleted SOLR-14735: > Katarzyna Zacharski > --- > > Key: SOLR-14735 > URL: https://issues.apache.org/jira/browse/SOLR-14735 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hannah Slaughter Zacharski >Priority: Major > -- 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] [Deleted] (SOLR-14736) Hannah Zacharski
[ https://issues.apache.org/jira/browse/SOLR-14736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya deleted SOLR-14736: > Hannah Zacharski > > > Key: SOLR-14736 > URL: https://issues.apache.org/jira/browse/SOLR-14736 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hannah Slaughter Zacharski >Priority: Major > -- 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] [Deleted] (SOLR-14738) CLONE - Mosby Zacharski
[ https://issues.apache.org/jira/browse/SOLR-14738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya deleted SOLR-14738: > CLONE - Mosby Zacharski > --- > > Key: SOLR-14738 > URL: https://issues.apache.org/jira/browse/SOLR-14738 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hannah Slaughter Zacharski >Priority: Major > -- 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] [Deleted] (SOLR-14737) Michael Zacharski
[ https://issues.apache.org/jira/browse/SOLR-14737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya deleted SOLR-14737: > Michael Zacharski > - > > Key: SOLR-14737 > URL: https://issues.apache.org/jira/browse/SOLR-14737 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hannah Slaughter Zacharski >Priority: Major > -- 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] [Deleted] (SOLR-14732) Lena Slaughter
[ https://issues.apache.org/jira/browse/SOLR-14732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya deleted SOLR-14732: > Lena Slaughter > -- > > Key: SOLR-14732 > URL: https://issues.apache.org/jira/browse/SOLR-14732 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hannah Slaughter Zacharski >Priority: Major > -- 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] [Deleted] (SOLR-14739) CLONE - Lena Slaughter
[ https://issues.apache.org/jira/browse/SOLR-14739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya deleted SOLR-14739: > CLONE - Lena Slaughter > -- > > Key: SOLR-14739 > URL: https://issues.apache.org/jira/browse/SOLR-14739 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hannah Slaughter Zacharski >Priority: Major > -- 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-14740) Boone Zacharski
Hannah Slaughter Zacharski created SOLR-14740: - Summary: Boone Zacharski Key: SOLR-14740 URL: https://issues.apache.org/jira/browse/SOLR-14740 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: Hannah Slaughter Zacharski Attachments: FEA2CE24-FF3B-40FB-80D5-0AAF749C0526.tiff -- 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-14741) CLONE - Boone Zacharski
Hannah Slaughter Zacharski created SOLR-14741: - Summary: CLONE - Boone Zacharski Key: SOLR-14741 URL: https://issues.apache.org/jira/browse/SOLR-14741 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: Hannah Slaughter Zacharski Attachments: FEA2CE24-FF3B-40FB-80D5-0AAF749C0526.tiff -- 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-14597) Advanced Query Parser
[ https://issues.apache.org/jira/browse/SOLR-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176494#comment-17176494 ] Ishan Chattopadhyaya commented on SOLR-14597: - I think we should build separate package for these, rather than loading them by default. > Advanced Query Parser > - > > Key: SOLR-14597 > URL: https://issues.apache.org/jira/browse/SOLR-14597 > Project: Solr > Issue Type: New Feature > Components: query parsers >Affects Versions: 8.6 >Reporter: Mike Nibeck >Assignee: Gus Heck >Priority: Major > > This JIRA ticket tracks the progress of SIP-9, the Advanced Query Parser that > is being donated by the Library of Congress. Full description of the feature > can be found on the SIP Page. > [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] > Briefly, this parser provides a comprehensive syntax for users that use > search on a daily basis. It also reserves a smaller set of punctuators than > other parsers. This facilitates easier handling of acronyms and punctuated > patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some > advanced features while also preventing access to arbitrary features via > local parameters. This parser will be safe for accepting user queries > directly with minimal pre-parsing, but for use cases beyond it's established > features alternate query paths (using other parsers) will need to be supplied. > The code drop is being prepared and will be supplied as soon as we receive > guidance from the PMC regarding the proper process. Given that the Library > already has a signed CCLA we need to understand which of these (or other > processes) apply: > [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] > and > [https://www.apache.org/licenses/contributor-agreements.html#grants] -- 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-14742) Katarzyna Zacharski
Hannah Slaughter Zacharski created SOLR-14742: - Summary: Katarzyna Zacharski Key: SOLR-14742 URL: https://issues.apache.org/jira/browse/SOLR-14742 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: Hannah Slaughter Zacharski Attachments: CF7F5D9A-731E-41D0-A807-AE3AC1A23CE9.jpeg -- 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-14743) CLONE - Katarzyna Zacharski
Hannah Slaughter Zacharski created SOLR-14743: - Summary: CLONE - Katarzyna Zacharski Key: SOLR-14743 URL: https://issues.apache.org/jira/browse/SOLR-14743 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: Hannah Slaughter Zacharski Attachments: CF7F5D9A-731E-41D0-A807-AE3AC1A23CE9.jpeg -- 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] [Comment Edited] (SOLR-14597) Advanced Query Parser
[ https://issues.apache.org/jira/browse/SOLR-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176494#comment-17176494 ] Ishan Chattopadhyaya edited comment on SOLR-14597 at 8/12/20, 5:14 PM: --- I think we should build separate package for these, rather than loading them by default. Now we have this done: SOLR-14151. was (Author: ichattopadhyaya): I think we should build separate package for these, rather than loading them by default. > Advanced Query Parser > - > > Key: SOLR-14597 > URL: https://issues.apache.org/jira/browse/SOLR-14597 > Project: Solr > Issue Type: New Feature > Components: query parsers >Affects Versions: 8.6 >Reporter: Mike Nibeck >Assignee: Gus Heck >Priority: Major > > This JIRA ticket tracks the progress of SIP-9, the Advanced Query Parser that > is being donated by the Library of Congress. Full description of the feature > can be found on the SIP Page. > [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] > Briefly, this parser provides a comprehensive syntax for users that use > search on a daily basis. It also reserves a smaller set of punctuators than > other parsers. This facilitates easier handling of acronyms and punctuated > patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some > advanced features while also preventing access to arbitrary features via > local parameters. This parser will be safe for accepting user queries > directly with minimal pre-parsing, but for use cases beyond it's established > features alternate query paths (using other parsers) will need to be supplied. > The code drop is being prepared and will be supplied as soon as we receive > guidance from the PMC regarding the proper process. Given that the Library > already has a signed CCLA we need to understand which of these (or other > processes) apply: > [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] > and > [https://www.apache.org/licenses/contributor-agreements.html#grants] -- 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-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya resolved SOLR-14151.
-
Fix Version/s: 8.7
Resolution: Fixed
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 10h 10m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
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] [Deleted] (SOLR-14740) Boone Zacharski
[ https://issues.apache.org/jira/browse/SOLR-14740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya deleted SOLR-14740: > Boone Zacharski > --- > > Key: SOLR-14740 > URL: https://issues.apache.org/jira/browse/SOLR-14740 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hannah Slaughter Zacharski >Priority: Major > -- 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] [Deleted] (SOLR-14743) CLONE - Katarzyna Zacharski
[ https://issues.apache.org/jira/browse/SOLR-14743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya deleted SOLR-14743: > CLONE - Katarzyna Zacharski > --- > > Key: SOLR-14743 > URL: https://issues.apache.org/jira/browse/SOLR-14743 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hannah Slaughter Zacharski >Priority: Major > -- 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] [Deleted] (SOLR-14741) CLONE - Boone Zacharski
[ https://issues.apache.org/jira/browse/SOLR-14741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya deleted SOLR-14741: > CLONE - Boone Zacharski > --- > > Key: SOLR-14741 > URL: https://issues.apache.org/jira/browse/SOLR-14741 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hannah Slaughter Zacharski >Priority: Major > -- 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] [Deleted] (SOLR-14742) Katarzyna Zacharski
[ https://issues.apache.org/jira/browse/SOLR-14742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya deleted SOLR-14742: > Katarzyna Zacharski > --- > > Key: SOLR-14742 > URL: https://issues.apache.org/jira/browse/SOLR-14742 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hannah Slaughter Zacharski >Priority: Major > -- 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-14744) Hannah Zacharski
Hannah Slaughter Zacharski created SOLR-14744: - Summary: Hannah Zacharski Key: SOLR-14744 URL: https://issues.apache.org/jira/browse/SOLR-14744 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Components: Admin UI, Authentication, Authorization, Backup/Restore, Build, config-api, contrib - Clustering, contrib - DataImportHandler, contrib - LangId, contrib - LTR, contrib - morphlines-cell, Data-driven Schema, documentation, Facet Module, Package Manager, Parallel SQL, replication (scripts), Schema and Analysis, scripts and tools, Server, SolrCLI, UpdateRequestProcessors Reporter: Hannah Slaughter Zacharski -- 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-14744) Hannah Zacharski
[ https://issues.apache.org/jira/browse/SOLR-14744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hannah Slaughter Zacharski updated SOLR-14744: -- Attachment: BF53BDD5-3F2A-4CA4-8EC0-5B92A8582E9B.jpeg > Hannah Zacharski > > > Key: SOLR-14744 > URL: https://issues.apache.org/jira/browse/SOLR-14744 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI, Authentication, Authorization, Backup/Restore, > Build, config-api, contrib - Clustering, contrib - DataImportHandler, contrib > - LangId, contrib - LTR, contrib - morphlines-cell, Data-driven Schema, > documentation, Facet Module, Package Manager, Parallel SQL, replication > (scripts), Schema and Analysis, scripts and tools, Server, SolrCLI, > UpdateRequestProcessors >Reporter: Hannah Slaughter Zacharski >Priority: Major > Attachments: BF53BDD5-3F2A-4CA4-8EC0-5B92A8582E9B.jpeg > > -- 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-14744) Hannah Zacharski
[ https://issues.apache.org/jira/browse/SOLR-14744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hannah Slaughter Zacharski updated SOLR-14744: -- Labels: LeaderElector l (was: ) > Hannah Zacharski > > > Key: SOLR-14744 > URL: https://issues.apache.org/jira/browse/SOLR-14744 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI, Authentication, Authorization, Backup/Restore, > Build, config-api, contrib - Clustering, contrib - DataImportHandler, contrib > - LangId, contrib - LTR, contrib - morphlines-cell, Data-driven Schema, > documentation, Facet Module, Package Manager, Parallel SQL, replication > (scripts), Schema and Analysis, scripts and tools, Server, SolrCLI, > UpdateRequestProcessors >Reporter: Hannah Slaughter Zacharski >Priority: Major > Labels: LeaderElector, l > Attachments: BF53BDD5-3F2A-4CA4-8EC0-5B92A8582E9B.jpeg > > -- 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
