[GitHub] [lucene-solr] johtani commented on issue #935: LUCENE-4056: Japanese Tokenizer (Kuromoji) cannot build UniDic dictionary
johtani commented on issue #935: LUCENE-4056: Japanese Tokenizer (Kuromoji) cannot build UniDic dictionary URL: https://github.com/apache/lucene-solr/pull/935#issuecomment-542527091 At least, I should paste the messages build successful for Unidic and Ipadic. And I will think tests for binary dictionaries. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] johtani commented on a change in pull request #935: LUCENE-4056: Japanese Tokenizer (Kuromoji) cannot build UniDic dictionary
johtani commented on a change in pull request #935: LUCENE-4056: Japanese Tokenizer (Kuromoji) cannot build UniDic dictionary URL: https://github.com/apache/lucene-solr/pull/935#discussion_r335285081 ## File path: lucene/analysis/kuromoji/ivy.xml ## @@ -19,19 +19,23 @@ - + + - + https://jaist.dl.sourceforge.net/project/mecab/mecab-ipadic/2.7.0-20070801/mecab-ipadic-2.7.0-20070801.tar.gz"/> https://rwthaachen.dl.osdn.jp/naist-jdic/53500/mecab-naist-jdic-0.6.3b-20111013.tar.gz"/> + + http://ja.osdn.net/frs/redir.php?m=iijf=unidic%2F58338%2Funidic-mecab-2.1.2_src.zip"/> Review comment: Thanks @msokolov and @mocobeta . I'll add the dictionary info in NOTICE.txt. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9008) Surround Query Parser NOT operator is binary (sort of)
Gus Heck created LUCENE-9008:
Summary: Surround Query Parser NOT operator is binary (sort of)
Key: LUCENE-9008
URL: https://issues.apache.org/jira/browse/LUCENE-9008
Project: Lucene - Core
Issue Type: Bug
Components: core/queryparser
Affects Versions: 8.3
Reporter: Gus Heck
The following query works in the surround query parser (tested via solr):
{code:java}
foo NOT bar{code}
However despite the Solr ref guide specifically noting that "NOT" is unary, the
following throw parsing exceptions (also tested in solr):
{code:java}
foo AND NOT bar{code}
{code:java}
NOT bar AND foo{code}
additionally the right hand side of NOT requires parenthesis for fielded
terms...
{code:java}
fizz NOT game:buzz {code}
throws an exception whereas
{code:java}
fizz NOT (game:buzz) {code}
keeps the parser happy.
The binary syntax may be intentional and certainly has a nice readability. The
parenthesis around fielded stuff seems arbitrary and just irritating. However,
this parser has been around for a long time so we probably won't want to go
changing it fundamentally.
I suggest that this ticket should provide some docs clarifying at least this
surprising syntax in the lucene package javadoc, the solr parser factory class
javadocs and the solr ref guide docs
([https://lucene.apache.org/solr/guide/8_1/other-parsers.html]) should be
corrected and expanded to at least clarify this surprising and quirky binary
NOT syntax.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9008) Surround Query Parser NOT operator is binary
[
https://issues.apache.org/jira/browse/LUCENE-9008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gus Heck updated LUCENE-9008:
-
Summary: Surround Query Parser NOT operator is binary (was: Surround Query
Parser NOT operator is binary (sort of))
> Surround Query Parser NOT operator is binary
>
>
> Key: LUCENE-9008
> URL: https://issues.apache.org/jira/browse/LUCENE-9008
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/queryparser
>Affects Versions: 8.3
>Reporter: Gus Heck
>Priority: Major
> Labels: documentation
>
> The following query works in the surround query parser (tested via solr):
> {code:java}
> foo NOT bar{code}
> However despite the Solr ref guide specifically noting that "NOT" is unary,
> the following throw parsing exceptions (also tested in solr):
> {code:java}
> foo AND NOT bar{code}
> {code:java}
> NOT bar AND foo{code}
> additionally the right hand side of NOT requires parenthesis for fielded
> terms...
> {code:java}
> fizz NOT game:buzz {code}
> throws an exception whereas
> {code:java}
> fizz NOT (game:buzz) {code}
> keeps the parser happy.
> The binary syntax may be intentional and certainly has a nice readability.
> The parenthesis around fielded stuff seems arbitrary and just irritating.
> However, this parser has been around for a long time so we probably won't
> want to go changing it fundamentally.
> I suggest that this ticket should provide some docs clarifying at least this
> surprising syntax in the lucene package javadoc, the solr parser factory
> class javadocs and the solr ref guide docs
> ([https://lucene.apache.org/solr/guide/8_1/other-parsers.html]) should be
> corrected and expanded to at least clarify this surprising and quirky binary
> NOT syntax.
--
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-8746) Make EdgeTree (aka ComponentTree) support different type of components
[
https://issues.apache.org/jira/browse/LUCENE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952512#comment-16952512
]
ASF subversion and git services commented on LUCENE-8746:
-
Commit b7309899e1b94e71c7fc867f79b77dcaed587ca6 in lucene-solr's branch
refs/heads/branch_8x from Ignacio Vera
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b730989 ]
LUCENE-8746: Call relate line with points in the same order as they
come from the original tessellation.
> Make EdgeTree (aka ComponentTree) support different type of components
> --
>
> Key: LUCENE-8746
> URL: https://issues.apache.org/jira/browse/LUCENE-8746
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ignacio Vera
>Priority: Major
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently the class {{EdgeTree}} is a bit confusing as it is in reality a
> tree of components. The inner class {{Edge}} is the one that builds a tree of
> edges which is used by Polygon2D and Line2D to represent their structure.
> Here is proposed:
> 1) Create a new class called {{ComponentTree}} which is in fact the current
> {{EdgeTree}}
> 2) Modify {{EdgeTree}} to be in fact the inner class Edge
> 3) Extract a {{Component}} interface so we can have different types of
> components in the same tree. This allow us to support heterogeneous trees of
> components.
> 4) Make {{Polygon2D}} and {{Line2D}} instance of the component interface.
> 4) With this change, {{LatLonShapePolygonQuery}} and {{LatLonShapeLineQuery}}
> can be replaced with one {{LatLonShapeComponentQuery.}}
>
>
>
--
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-8746) Make EdgeTree (aka ComponentTree) support different type of components
[
https://issues.apache.org/jira/browse/LUCENE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952511#comment-16952511
]
ASF subversion and git services commented on LUCENE-8746:
-
Commit 39fcd907fb38df060f0b74b50e22afba8ae37892 in lucene-solr's branch
refs/heads/master from Ignacio Vera
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=39fcd90 ]
LUCENE-8746: Call relate line with points in the same order as they
come from the original tessellation.
> Make EdgeTree (aka ComponentTree) support different type of components
> --
>
> Key: LUCENE-8746
> URL: https://issues.apache.org/jira/browse/LUCENE-8746
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ignacio Vera
>Priority: Major
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently the class {{EdgeTree}} is a bit confusing as it is in reality a
> tree of components. The inner class {{Edge}} is the one that builds a tree of
> edges which is used by Polygon2D and Line2D to represent their structure.
> Here is proposed:
> 1) Create a new class called {{ComponentTree}} which is in fact the current
> {{EdgeTree}}
> 2) Modify {{EdgeTree}} to be in fact the inner class Edge
> 3) Extract a {{Component}} interface so we can have different types of
> components in the same tree. This allow us to support heterogeneous trees of
> components.
> 4) Make {{Polygon2D}} and {{Line2D}} instance of the component interface.
> 4) With this change, {{LatLonShapePolygonQuery}} and {{LatLonShapeLineQuery}}
> can be replaced with one {{LatLonShapeComponentQuery.}}
>
>
>
--
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] jgq2008303393 edited a comment on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries
jgq2008303393 edited a comment on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries URL: https://github.com/apache/lucene-solr/pull/940#issuecomment-542508279 @wuyunfeng Whether to cache a composite clause or a single clause needs to be determined according to the scenario. For queries are like this: host_ip:xxx AND timestamp:[start, end], if host_ip clause and timestamp clause always have the same parameter value, only the composite clause should be cached. However if host_ip clause has different parameter values in each query, which is a real scenario, it makes more sense to only cache timestamp clause. That's why Lucene cache clause according to frequency. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jgq2008303393 commented on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries
jgq2008303393 commented on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries URL: https://github.com/apache/lucene-solr/pull/940#issuecomment-542508279 @wuyunfeng Whether to cache a composite clause or a single clause needs to be determined according to the scenario. For queries are like this: host_ip:xxx AND timestamp:[start, end], if host_ip clause and timestamp clause always have the same parameter value, only the composite clause should be cached. However if host_ip clause has different parameter values in each query, which is the real situation, it makes more sense to only cache timestamp clause. That's why Lucene cache clause according to frequency. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))
[ https://issues.apache.org/jira/browse/LUCENE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952483#comment-16952483 ] Huy Le commented on LUCENE-8041: [~dsmiley] is there anyway we can move forward with this ticket ? > All Fields.terms(fld) impls should be O(1) not O(log(N)) > > > Key: LUCENE-8041 > URL: https://issues.apache.org/jira/browse/LUCENE-8041 > Project: Lucene - Core > Issue Type: Improvement >Reporter: David Wayne Smiley >Priority: Major > Attachments: LUCENE-8041-LinkedHashMap.patch, LUCENE-8041.patch > > > I've seen apps that have a good number of fields -- hundreds. The O(log(N)) > of TreeMap definitely shows up in a profiler; sometimes 20% of search time, > if I recall. There are many Field implementations that are impacted... in > part because Fields is the base class of FieldsProducer. > As an aside, I hope Fields to go away some day; FieldsProducer should be > TermsProducer and not have an iterator of fields. If DocValuesProducer > doesn't have this then why should the terms index part of our API have it? > If we did this then the issue here would be a simple transition to a HashMap. > Or maybe we can switch to HashMap and relax the definition of Fields.iterator > to not necessarily be sorted? > Perhaps the fix can be a relatively simple conversion over to LinkedHashMap > in many cases if we can assume when we initialize these internal maps that we > consume them in sorted order to begin with. -- 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-12769) Incorrect documentation for Request Parameter API names (unset/delete)
[
https://issues.apache.org/jira/browse/SOLR-12769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952462#comment-16952462
]
Lucene/Solr QA commented on SOLR-12769:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
50s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 0m 54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 0m 51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate ref guide {color} |
{color:green} 0m 51s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 5m
31s{color} | {color:green} solrj in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 8m 19s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12769 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12983011/SOLR-12769.patch |
| Optional Tests | compile javac unit ratsources validatesourcepatterns
validaterefguide |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 939b3364e60 |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/577/testReport/ |
| modules | C: solr/solrj solr/solr-ref-guide U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/577/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Incorrect documentation for Request Parameter API names (unset/delete)
> ---
>
> Key: SOLR-12769
> URL: https://issues.apache.org/jira/browse/SOLR-12769
> Project: Solr
> Issue Type: Bug
> Components: documentation
>Affects Versions: 7.4
>Reporter: Alexandre Rafalovitch
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-12769.patch, SOLR-12769.patch
>
>
> The [documentation for the Request Parameter
> APIhttps://lucene.apache.org/solr/guide/7_4/request-parameters-api.html#setting-request-parameters]
> names operations as set/update/unset.
> So does the introspection.
> However, the code for the SolrConfigHandler#handleParams uses
> set/update/delete. So, the *unset* is not a correct description. The manual
> testing also shows only *delete* command working.
> Furthermore, the format of the delete command is different from others
> (array, not map), so this should be documented as well.
--
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-12742) Improve documentation for auto add replicas and trigger documentation
[
https://issues.apache.org/jira/browse/SOLR-12742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-12742:
-
Fix Version/s: (was: master (9.0))
> Improve documentation for auto add replicas and trigger documentation
> -
>
> Key: SOLR-12742
> URL: https://issues.apache.org/jira/browse/SOLR-12742
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling, documentation, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Major
>
> After SOLR-12715, the documentation (and user story) around the auto add
> replicas feature is inconsistent. This is because even though we can now add
> new replicas automatically on new nodes, the {{autoAddReplicas=true}}
> parameter on the create collection API only moves replicas around to replace
> the lost replicas. We should try to fix our documentation first to describe
> these two features in a coherent way and open another issue, if needed, to
> change the behavior of autoAddReplicas parameter in Solr 8.0.
--
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-12742) Improve documentation for auto add replicas and trigger documentation
[
https://issues.apache.org/jira/browse/SOLR-12742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-12742:
-
Fix Version/s: (was: 8.1)
> Improve documentation for auto add replicas and trigger documentation
> -
>
> Key: SOLR-12742
> URL: https://issues.apache.org/jira/browse/SOLR-12742
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling, documentation, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (9.0)
>
>
> After SOLR-12715, the documentation (and user story) around the auto add
> replicas feature is inconsistent. This is because even though we can now add
> new replicas automatically on new nodes, the {{autoAddReplicas=true}}
> parameter on the create collection API only moves replicas around to replace
> the lost replicas. We should try to fix our documentation first to describe
> these two features in a coherent way and open another issue, if needed, to
> change the behavior of autoAddReplicas parameter in Solr 8.0.
--
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] [Assigned] (SOLR-12742) Improve documentation for auto add replicas and trigger documentation
[
https://issues.apache.org/jira/browse/SOLR-12742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett reassigned SOLR-12742:
Assignee: (was: Cassandra Targett)
> Improve documentation for auto add replicas and trigger documentation
> -
>
> Key: SOLR-12742
> URL: https://issues.apache.org/jira/browse/SOLR-12742
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling, documentation, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 8.1, master (9.0)
>
>
> After SOLR-12715, the documentation (and user story) around the auto add
> replicas feature is inconsistent. This is because even though we can now add
> new replicas automatically on new nodes, the {{autoAddReplicas=true}}
> parameter on the create collection API only moves replicas around to replace
> the lost replicas. We should try to fix our documentation first to describe
> these two features in a coherent way and open another issue, if needed, to
> change the behavior of autoAddReplicas parameter in Solr 8.0.
--
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-12961) Ref Guide: Add keyword metadata to pages
[
https://issues.apache.org/jira/browse/SOLR-12961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-12961:
-
Fix Version/s: (was: 8.1)
(was: master (9.0))
> Ref Guide: Add keyword metadata to pages
>
>
> Key: SOLR-12961
> URL: https://issues.apache.org/jira/browse/SOLR-12961
> Project: Solr
> Issue Type: Improvement
> Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
> Attachments: SOLR-12961.patch, keywords.json, userlevels.json
>
>
> As a continuation of improvements in SOLR-12746, another thing we should do
> is add keyword metadata to the HTML pages. Currently our pages have this in
> the {{}} section:
> {code}
>
> {code}
> We have the structure in place for it in the page templates, we just need to
> populate with some keywords.
> The idea behind doing this is that these terms could be a source for facet
> buckets when we get a Ref Guide search going via SOLR-10299.
--
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] ctargett commented on issue #723: SOLR-13545: AutoClose stream in ContentStreamUpdateRequest
ctargett commented on issue #723: SOLR-13545: AutoClose stream in ContentStreamUpdateRequest URL: https://github.com/apache/lucene-solr/pull/723#issuecomment-542462754 Confused what's happening with this PR - https://issues.apache.org/jira/browse/SOLR-13545 is closed, so can this be closed? Is there something here that should be spun into a new Jira issue for future contribution? 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ctargett commented on issue #643: SOLR-13391: Add variance and standard deviation stream evaluators
ctargett commented on issue #643: SOLR-13391: Add variance and standard deviation stream evaluators URL: https://github.com/apache/lucene-solr/pull/643#issuecomment-542461299 Closed PR since the code has been merged and released. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ctargett closed pull request #643: SOLR-13391: Add variance and standard deviation stream evaluators
ctargett closed pull request #643: SOLR-13391: Add variance and standard deviation stream evaluators URL: https://github.com/apache/lucene-solr/pull/643 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13846) PreemptiveBasicAuthClientBuilderFactory use of static code blocks makes it unreliable in tests
[
https://issues.apache.org/jira/browse/SOLR-13846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952355#comment-16952355
]
ASF subversion and git services commented on SOLR-13846:
Commit 59548c16d36523de61c75881fa5981a629c046cd in lucene-solr's branch
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=59548c1 ]
SOLR-13846: workaround - elliminate use of problematic
PreemptiveBasicAuthClientBuilderFactory in tests that don't need it
(cherry picked from commit 939b3364e604a4a16b3c4c5f278c4d7f30f1354b)
> PreemptiveBasicAuthClientBuilderFactory use of static code blocks makes it
> unreliable in tests
> --
>
> Key: SOLR-13846
> URL: https://issues.apache.org/jira/browse/SOLR-13846
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> PreemptiveBasicAuthClientBuilderFactory uses static code blocks to initialize
> global static variables in a way that makes it largely unusable in tests.
> Notably: it uses {{System.getProperty(...)}} during classloading to read
> system properties that then affect the behavior of all future instances --
> even if an individual test explicitly sets the system property in question
> before instaniating instances of this class.
> This means that if two tests that both use instances of
> PreemptiveBasicAuthClientBuilderFactory run in the same JVM, only the system
> properties set in the first test will be used by
> PreemptiveBasicAuthClientBuilderFactory in the *second* test (even those the
> system properties get reset by the test framework between runs)
> There are currently two tests using PreemptiveBasicAuthClientBuilderFactory,
> and depending on the order they run, one will fail...
> {noformat}
> $ ant test -Dtests.jvms=1
> '-Dtests.class=*.TestQueryingOnDownCollection|*.BasicAuthOnSingleNodeTest'
> -Dtests.seed=EC8FB67A91689F48 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sl -Dtests.timezone=Asia/Baghdad -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
> ...
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=BasicAuthOnSingleNodeTest -Dtests.method=basicTest
> -Dtests.seed=EC8FB67A91689F48 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sl -Dtests.timezone=Asia/Baghdad -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR 4.05s | BasicAuthOnSingleNodeTest.basicTest <<<
>[junit4]> Throwable #1:
> org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException:
> Error from server at http://127.0.0.1:37047/solr: Expected mime type
> application/octet-stream but got text/html.
>[junit4]>
>[junit4]> content="text/html;charset=utf-8"/>
>[junit4]> Error 401 Bad credentials
>[junit4]>
>[junit4]> HTTP ERROR 401
>[junit4]> Problem accessing /solr/authCollection/select. Reason:
>[junit4]> Bad credentials href="http://eclipse.org/jetty;>Powered by Jetty:// 9.4.19.v20190610
>[junit4]>
>[junit4]>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([EC8FB67A91689F48:1E7BA118D5CD927B]:0)
>[junit4]> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.processErrorsAndResponse(Http2SolrClient.java:696)
>[junit4]> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:402)
>[junit4]> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:754)
>[junit4]> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
>[junit4]> at
> org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1003)
>[junit4]> at
> org.apache.solr.security.BasicAuthOnSingleNodeTest.basicTest(BasicAuthOnSingleNodeTest.java:72)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:834)
> {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-13846) PreemptiveBasicAuthClientBuilderFactory use of static code blocks makes it unreliable in tests
[
https://issues.apache.org/jira/browse/SOLR-13846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952344#comment-16952344
]
ASF subversion and git services commented on SOLR-13846:
Commit 939b3364e604a4a16b3c4c5f278c4d7f30f1354b in lucene-solr's branch
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=939b336 ]
SOLR-13846: workaround - elliminate use of problematic
PreemptiveBasicAuthClientBuilderFactory in tests that don't need it
> PreemptiveBasicAuthClientBuilderFactory use of static code blocks makes it
> unreliable in tests
> --
>
> Key: SOLR-13846
> URL: https://issues.apache.org/jira/browse/SOLR-13846
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> PreemptiveBasicAuthClientBuilderFactory uses static code blocks to initialize
> global static variables in a way that makes it largely unusable in tests.
> Notably: it uses {{System.getProperty(...)}} during classloading to read
> system properties that then affect the behavior of all future instances --
> even if an individual test explicitly sets the system property in question
> before instaniating instances of this class.
> This means that if two tests that both use instances of
> PreemptiveBasicAuthClientBuilderFactory run in the same JVM, only the system
> properties set in the first test will be used by
> PreemptiveBasicAuthClientBuilderFactory in the *second* test (even those the
> system properties get reset by the test framework between runs)
> There are currently two tests using PreemptiveBasicAuthClientBuilderFactory,
> and depending on the order they run, one will fail...
> {noformat}
> $ ant test -Dtests.jvms=1
> '-Dtests.class=*.TestQueryingOnDownCollection|*.BasicAuthOnSingleNodeTest'
> -Dtests.seed=EC8FB67A91689F48 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sl -Dtests.timezone=Asia/Baghdad -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
> ...
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=BasicAuthOnSingleNodeTest -Dtests.method=basicTest
> -Dtests.seed=EC8FB67A91689F48 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sl -Dtests.timezone=Asia/Baghdad -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR 4.05s | BasicAuthOnSingleNodeTest.basicTest <<<
>[junit4]> Throwable #1:
> org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException:
> Error from server at http://127.0.0.1:37047/solr: Expected mime type
> application/octet-stream but got text/html.
>[junit4]>
>[junit4]> content="text/html;charset=utf-8"/>
>[junit4]> Error 401 Bad credentials
>[junit4]>
>[junit4]> HTTP ERROR 401
>[junit4]> Problem accessing /solr/authCollection/select. Reason:
>[junit4]> Bad credentials href="http://eclipse.org/jetty;>Powered by Jetty:// 9.4.19.v20190610
>[junit4]>
>[junit4]>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([EC8FB67A91689F48:1E7BA118D5CD927B]:0)
>[junit4]> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.processErrorsAndResponse(Http2SolrClient.java:696)
>[junit4]> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:402)
>[junit4]> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:754)
>[junit4]> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
>[junit4]> at
> org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1003)
>[junit4]> at
> org.apache.solr.security.BasicAuthOnSingleNodeTest.basicTest(BasicAuthOnSingleNodeTest.java:72)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:834)
> {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
[GitHub] [lucene-solr] uschindler edited a comment on issue #954: LUCENE-9007: MockSynonymFilter should add TypeAttribute
uschindler edited a comment on issue #954: LUCENE-9007: MockSynonymFilter should add TypeAttribute URL: https://github.com/apache/lucene-solr/pull/954#issuecomment-542433616 No idea about the precommit check. I can look into that tomorrow. Should I take the issue? Looks fine to me and it allows is to create better tests in the future. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] uschindler commented on issue #954: LUCENE-9007: MockSynonymFilter should add TypeAttribute
uschindler commented on issue #954: LUCENE-9007: MockSynonymFilter should add TypeAttribute URL: https://github.com/apache/lucene-solr/pull/954#issuecomment-542433616 No idea about the precommit check. I can look into that tomorrow. Should I take the issue. Looks fine to me and it allows is to create better tests in the future. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13849) TestSnapshotCloudManager.testSimulatorFromSnapshot failure due to running trigger
[
https://issues.apache.org/jira/browse/SOLR-13849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952331#comment-16952331
]
Chris M. Hostetter commented on SOLR-13849:
---
full error w/o paraphrasing...
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestSnapshotCloudManager -Dtests.method=testSimulatorFromSnapshot
-Dtests.seed=275551978EB
3DD11 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=fr-MC
-Dtests.timezone=Asia/Jakarta -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] FAILURE 0.17s J2 |
TestSnapshotCloudManager.testSimulatorFromSnapshot <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<[/,
/aliases.json, /autoscaling, /autoscaling.json, /autoscaling/events,
/autoscaling/events/.auto_add_replicas,
/autoscaling/events/.scheduled_maintenance, /autoscaling/nodeAdded,
/autoscaling/nodeLost, /clusterprops.json, /collections, /collections/.system,
/collections/.system/counter, /collections/.system/leader_elect,
/collections/.system/leaders, /collections/.system/state.json,
/collections/.system/terms, /collections/.system/terms/shard1,
/collections/coll1, /collections/coll1/counter,
/collections/coll1/leader_elect, /collections/coll1/leaders,
/collections/coll1/state.json, /collections/coll1/terms,
/collections/coll1/terms/shard1, /collections/coll10,
/collections/coll10/counter, /collections/coll10/leader_elect,
/collections/coll10/leaders, /collections/coll10/state.json,
/collections/coll10/terms, /collections/coll10/terms/shard1, /configs,
/configs/.system, /configs/.system/managed-schema,
/configs/.system/schema.xml.bak, /configs/.system/solrconfig.xml,
/configs/_default, /configs/_default/lang,
/configs/_default/lang/contractions_ca.txt,
/configs/_default/lang/contractions_fr.txt,
/configs/_default/lang/contractions_ga.txt,
/configs/_default/lang/contractions_it.txt,
/configs/_default/lang/hyphenations_ga.txt,
/configs/_default/lang/stemdict_nl.txt, /configs/_default/lang/stoptags_ja.txt,
/configs/_default/lang/stopwords_ar.txt,
/configs/_default/lang/stopwords_bg.txt,
/configs/_default/lang/stopwords_ca.txt,
/configs/_default/lang/stopwords_cz.txt,
/configs/_default/lang/stopwords_da.txt,
/configs/_default/lang/stopwords_de.txt,
/configs/_default/lang/stopwords_el.txt,
/configs/_default/lang/stopwords_en.txt,
/configs/_default/lang/stopwords_es.txt,
/configs/_default/lang/stopwords_et.txt,
/configs/_default/lang/stopwords_eu.txt,
/configs/_default/lang/stopwords_fa.txt,
/configs/_default/lang/stopwords_fi.txt,
/configs/_default/lang/stopwords_fr.txt,
/configs/_default/lang/stopwords_ga.txt,
/configs/_default/lang/stopwords_gl.txt,
/configs/_default/lang/stopwords_hi.txt,
/configs/_default/lang/stopwords_hu.txt,
/configs/_default/lang/stopwords_hy.txt,
/configs/_default/lang/stopwords_id.txt,
/configs/_default/lang/stopwords_it.txt,
/configs/_default/lang/stopwords_ja.txt,
/configs/_default/lang/stopwords_lv.txt,
/configs/_default/lang/stopwords_nl.txt,
/configs/_default/lang/stopwords_no.txt,
/configs/_default/lang/stopwords_pt.txt,
/configs/_default/lang/stopwords_ro.txt,
/configs/_default/lang/stopwords_ru.txt,
/configs/_default/lang/stopwords_sv.txt,
/configs/_default/lang/stopwords_th.txt,
/configs/_default/lang/stopwords_tr.txt,
/configs/_default/lang/userdict_ja.txt, /configs/_default/managed-schema,
/configs/_default/params.json, /configs/_default/protwords.txt,
/configs/_default/solrconfig.xml, /configs/_default/stopwords.txt,
/configs/_default/synonyms.txt, /configs/coll1.AUTOCREATED,
/configs/coll1.AUTOCREATED/lang,
/configs/coll1.AUTOCREATED/lang/contractions_ca.txt,
/configs/coll1.AUTOCREATED/lang/contractions_fr.txt,
/configs/coll1.AUTOCREATED/lang/contractions_ga.txt,
/configs/coll1.AUTOCREATED/lang/contractions_it.txt,
/configs/coll1.AUTOCREATED/lang/hyphenations_ga.txt,
/configs/coll1.AUTOCREATED/lang/stemdict_nl.txt,
/configs/coll1.AUTOCREATED/lang/stoptags_ja.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_ar.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_bg.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_ca.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_cz.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_da.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_de.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_el.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_en.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_es.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_et.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_eu.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_fa.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_fi.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_fr.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_ga.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_gl.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_hi.txt,
/configs/coll1.AUTOCREATED/lang/stopwords_hu.txt,
[jira] [Created] (SOLR-13849) TestSnapshotCloudManager.testSimulatorFromSnapshot failure due to running trigger
Chris M. Hostetter created SOLR-13849:
-
Summary: TestSnapshotCloudManager.testSimulatorFromSnapshot
failure due to running trigger
Key: SOLR-13849
URL: https://issues.apache.org/jira/browse/SOLR-13849
Project: Solr
Issue Type: Test
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Chris M. Hostetter
Assignee: Andrzej Bialecki
recent jenkins failure from TestSnapshotCloudManager.testSimulatorFromSnapshot
suggests that the problem is atemping to compare the ZK tree from the snapshot
with the ZK tree of the running system while a trigger has fired creating an
ephemeral node...
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestSnapshotCloudManager -Dtests.method=testSimulatorFromSnapshot
-Dtests.seed=275551978EB
3DD11 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=fr-MC
-Dtests.timezone=Asia/Jakarta -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] FAILURE 0.17s J2 |
TestSnapshotCloudManager.testSimulatorFromSnapshot <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<[ ... ]> but
was:<[ ... , /autoscaling/events/.scheduled_maintenance/qn-00, ... ]>
[junit4]>at
__randomizedtesting.SeedInfo.seed([275551978EB3DD11:491E5C4CE071E7FD]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.sim.TestSnapshotCloudManager.assertDistribStateManager(TestSnapshotCloudManager.java:241)
[junit4]>at
org.apache.solr.cloud.autoscaling.sim.TestSnapshotCloudManager.testSimulatorFromSnapshot(TestSnapshotCloudManager.java:157)
[junit4]>at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4]>at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit4]>at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4]>at
java.base/java.lang.reflect.Method.invoke(Method.java:564)
[junit4]>at java.base/java.lang.Thread.run(Thread.java:830)
{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-13846) PreemptiveBasicAuthClientBuilderFactory use of static code blocks makes it unreliable in tests
[
https://issues.apache.org/jira/browse/SOLR-13846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952291#comment-16952291
]
Chris M. Hostetter commented on SOLR-13846:
---
i can't really wrap my head around how/why it fails the way it does – but more
importantly: nothing in either of these 2 affected tests actual cares about
using PreemptiveBasicAuthClientBuilderFactory:
* BasicAuthOnSingleNodeTest explicitly sets the credentials on most requests,
and seems to use PreemptiveBasicAuthClientBuilderFactory purely as a way to
ensure credentials are set when querying with the {{SolrQuery}} API (which
doesn't have credential realted methods
** using the more full featured {{QueryRequest}} API in it's place and setting
credentials on those objects works just as well
* TestQueryingOnDownCollection already explicitly sets the credentials on
every request
** removing the initialization of PreemptiveBasicAuthClientBuilderFactory from
this test has zero impact on it's behavior.
...so i'm going to go ahead and remove PreemptiveBasicAuthClientBuilderFactory
from these tests, and leave this issue open for the future to fix
PreemptiveBasicAuthClientBuilderFactory so more then one instance could
potentially be used in a single JVM.
> PreemptiveBasicAuthClientBuilderFactory use of static code blocks makes it
> unreliable in tests
> --
>
> Key: SOLR-13846
> URL: https://issues.apache.org/jira/browse/SOLR-13846
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> PreemptiveBasicAuthClientBuilderFactory uses static code blocks to initialize
> global static variables in a way that makes it largely unusable in tests.
> Notably: it uses {{System.getProperty(...)}} during classloading to read
> system properties that then affect the behavior of all future instances --
> even if an individual test explicitly sets the system property in question
> before instaniating instances of this class.
> This means that if two tests that both use instances of
> PreemptiveBasicAuthClientBuilderFactory run in the same JVM, only the system
> properties set in the first test will be used by
> PreemptiveBasicAuthClientBuilderFactory in the *second* test (even those the
> system properties get reset by the test framework between runs)
> There are currently two tests using PreemptiveBasicAuthClientBuilderFactory,
> and depending on the order they run, one will fail...
> {noformat}
> $ ant test -Dtests.jvms=1
> '-Dtests.class=*.TestQueryingOnDownCollection|*.BasicAuthOnSingleNodeTest'
> -Dtests.seed=EC8FB67A91689F48 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sl -Dtests.timezone=Asia/Baghdad -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
> ...
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=BasicAuthOnSingleNodeTest -Dtests.method=basicTest
> -Dtests.seed=EC8FB67A91689F48 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sl -Dtests.timezone=Asia/Baghdad -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR 4.05s | BasicAuthOnSingleNodeTest.basicTest <<<
>[junit4]> Throwable #1:
> org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException:
> Error from server at http://127.0.0.1:37047/solr: Expected mime type
> application/octet-stream but got text/html.
>[junit4]>
>[junit4]> content="text/html;charset=utf-8"/>
>[junit4]> Error 401 Bad credentials
>[junit4]>
>[junit4]> HTTP ERROR 401
>[junit4]> Problem accessing /solr/authCollection/select. Reason:
>[junit4]> Bad credentials href="http://eclipse.org/jetty;>Powered by Jetty:// 9.4.19.v20190610
>[junit4]>
>[junit4]>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([EC8FB67A91689F48:1E7BA118D5CD927B]:0)
>[junit4]> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.processErrorsAndResponse(Http2SolrClient.java:696)
>[junit4]> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:402)
>[junit4]> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:754)
>[junit4]> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
>[junit4]> at
> org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1003)
>[junit4]> at
> org.apache.solr.security.BasicAuthOnSingleNodeTest.basicTest(BasicAuthOnSingleNodeTest.java:72)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
>
[GitHub] [lucene-solr] epugh opened a new pull request #956: SOLR-13848 tweak documentation to be clearer about uprefix
epugh opened a new pull request #956: SOLR-13848 tweak documentation to be clearer about uprefix URL: https://github.com/apache/lucene-solr/pull/956 # Description Tweak How to use Solr Cell doc # Solution Simplifying parameters in initial example query. # Tests Tested in Solr 8.2 # Checklist Please review the following and check all that apply: - [x ] 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. - [x ] I have created a Jira issue and added the issue ID to my pull request title. - [x ] I am authorized to contribute this code to the ASF and have removed any code I do not have a license to distribute. - [ ] 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) - [ X] 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. - [ X] 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13848) Documentation on how to run curl to extract a document isn't clear.
[ https://issues.apache.org/jira/browse/SOLR-13848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Eric Pugh updated SOLR-13848: --- Status: Patch Available (was: Open) > Documentation on how to run curl to extract a document isn't clear. > --- > > Key: SOLR-13848 > URL: https://issues.apache.org/jira/browse/SOLR-13848 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 8.2 >Reporter: David Eric Pugh >Priority: Minor > > In the "Trying out Solr Cell" section the curl command includes the > parameters `uprefix=ignored_`, which then means that all of the extracted > fields are ignored.. Yet this is your very first command, so when you query > solr you don't see any extracted data! had me confused! > Let's try and be clearer in the onboarding step. -- 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-13848) Documentation on how to run curl to extract a document isn't clear.
David Eric Pugh created SOLR-13848: -- Summary: Documentation on how to run curl to extract a document isn't clear. Key: SOLR-13848 URL: https://issues.apache.org/jira/browse/SOLR-13848 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: contrib - Solr Cell (Tika extraction) Affects Versions: 8.2 Reporter: David Eric Pugh In the "Trying out Solr Cell" section the curl command includes the parameters `uprefix=ignored_`, which then means that all of the extracted fields are ignored.. Yet this is your very first command, so when you query solr you don't see any extracted data! had me confused! Let's try and be clearer in the onboarding step. -- 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-13847) Fix ref guide for autoscaling metric trigger
[
https://issues.apache.org/jira/browse/SOLR-13847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ROCHETEAU Antoine updated SOLR-13847:
-
Priority: Minor (was: Trivial)
> Fix ref guide for autoscaling metric trigger
>
>
> Key: SOLR-13847
> URL: https://issues.apache.org/jira/browse/SOLR-13847
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 7.7.2, 8.2
>Reporter: ROCHETEAU Antoine
>Priority: Minor
> Attachments: metric_trigger_documentation.patch
>
>
> Reported in the IRC channel who ask me to raise an issue,
> The documentation for the autoscaling metric trigger have an error on the
> description (it's not possible to set up a basic metric trigger with the
> current documentation).
> [https://lucene.apache.org/solr/guide/8_1/solrcloud-autoscaling-triggers.html#metric-trigger]
> metric:_group_:_prefix_ should be replaced by
> metric{color:#ff}s{color}:_group_:_prefix_
> This correction is also required on the example:
> {{metric{color:#ff}s{color}:solr.node:CONTAINER.fs.coreRoot.usableSpace}}
> This is confirmed by the source code with explicit use of "metrics:" (see
> for example: org.apache.solr.cloud.autoscaling.sim.SimNodeStateProvider or
> org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest)
--
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-9005) BooleanQuery.visit() incorrectly pulls subvisitors from its parent
[
https://issues.apache.org/jira/browse/LUCENE-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952251#comment-16952251
]
Alan Woodward commented on LUCENE-9005:
---
Right, we could go either way. MUST seems more natural to me, but I guess
that's just because it's been around longer.
> BooleanQuery.visit() incorrectly pulls subvisitors from its parent
> --
>
> Key: LUCENE-9005
> URL: https://issues.apache.org/jira/browse/LUCENE-9005
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-9005.patch
>
>
> BooleanQuery.visit() calls getSubVisitor once for each of its clause sets;
> however, this sub visitor is called on the passed-in visitor, which means
> that sub clauses get attached to its parent, rather than a visitor for that
> particular BQ.
> To illustrate, consider the following nested BooleanQuery: ("a b" (+c +d %e
> f)); we have a top-level disjunction query containing one phrase query
> (essentially a conjunction), and one boolean query containing both MUST,
> FILTER and SHOULD clauses. When visiting, the top level query will pull a
> SHOULD subvisitor, and pass both queries into it. The phrase query will pull
> a MUST subvisitor and all its two terms. The nested boolean will pull a
> MUST, and FILTER and a SHOULD; but these are all attached to the parent
> SHOULD visitor - in particular, the MUST and FILTER clauses will end up being
> attached to this SHOULD visitor, and be mis-interpreted as a disjunction.
> To fix this, BQ should first pull a MUST visitor and visit its MUST clauses
> using this visitor; SHOULD, FILTER and MUST_NOT clauses should then be pulled
> from this top-level MUST visitor.
--
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-13847) Fix ref guide for autoscaling metric trigger
[
https://issues.apache.org/jira/browse/SOLR-13847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ROCHETEAU Antoine updated SOLR-13847:
-
Attachment: (was: metric_trigger_documentation.patch)
> Fix ref guide for autoscaling metric trigger
>
>
> Key: SOLR-13847
> URL: https://issues.apache.org/jira/browse/SOLR-13847
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 7.7.2, 8.2
>Reporter: ROCHETEAU Antoine
>Priority: Trivial
> Attachments: metric_trigger_documentation.patch
>
>
> Reported in the IRC channel who ask me to raise an issue,
> The documentation for the autoscaling metric trigger have an error on the
> description (it's not possible to set up a basic metric trigger with the
> current documentation).
> [https://lucene.apache.org/solr/guide/8_1/solrcloud-autoscaling-triggers.html#metric-trigger]
> metric:_group_:_prefix_ should be replaced by
> metric{color:#ff}s{color}:_group_:_prefix_
> This correction is also required on the example:
> {{metric{color:#ff}s{color}:solr.node:CONTAINER.fs.coreRoot.usableSpace}}
> This is confirmed by the source code with explicit use of "metrics:" (see
> for example: org.apache.solr.cloud.autoscaling.sim.SimNodeStateProvider or
> org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest)
--
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-13847) Fix ref guide for autoscaling metric trigger
[
https://issues.apache.org/jira/browse/SOLR-13847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ROCHETEAU Antoine updated SOLR-13847:
-
Attachment: metric_trigger_documentation.patch
> Fix ref guide for autoscaling metric trigger
>
>
> Key: SOLR-13847
> URL: https://issues.apache.org/jira/browse/SOLR-13847
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 7.7.2, 8.2
>Reporter: ROCHETEAU Antoine
>Priority: Trivial
> Attachments: metric_trigger_documentation.patch
>
>
> Reported in the IRC channel who ask me to raise an issue,
> The documentation for the autoscaling metric trigger have an error on the
> description (it's not possible to set up a basic metric trigger with the
> current documentation).
> [https://lucene.apache.org/solr/guide/8_1/solrcloud-autoscaling-triggers.html#metric-trigger]
> metric:_group_:_prefix_ should be replaced by
> metric{color:#ff}s{color}:_group_:_prefix_
> This correction is also required on the example:
> {{metric{color:#ff}s{color}:solr.node:CONTAINER.fs.coreRoot.usableSpace}}
> This is confirmed by the source code with explicit use of "metrics:" (see
> for example: org.apache.solr.cloud.autoscaling.sim.SimNodeStateProvider or
> org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest)
--
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-13847) Fix ref guide for autoscaling metric trigger
[
https://issues.apache.org/jira/browse/SOLR-13847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ROCHETEAU Antoine updated SOLR-13847:
-
Description:
Reported in the IRC channel who ask me to raise an issue,
The documentation for the autoscaling metric trigger have an error on the
description (it's not possible to set up a basic metric trigger with the
current documentation).
[https://lucene.apache.org/solr/guide/8_1/solrcloud-autoscaling-triggers.html#metric-trigger]
metric:_group_:_prefix_ should be replaced by
metric*{color:#ff}s{color}*:_group_:_prefix_
This correction is also required on the example:
{{metric*{color:#ff}s{color}*:solr.node:CONTAINER.fs.coreRoot.usableSpace}}
This is confirmed by the source code with explicit use of "metrics:" (see for
example: org.apache.solr.cloud.autoscaling.sim.SimNodeStateProvider or
org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest)
was:
Reported in the IRC channel who ask me to raise an issue,
The documentation for the autoscaling metric trigger have an error on the
description (it's not possible to set up a basic metric trigger with the
current documentation).
[https://lucene.apache.org/solr/guide/8_1/solrcloud-autoscaling-triggers.html#metric-trigger]
metric:_group_:_prefix_ should be replaced by
metric*{color:#FF}s{color}*:_group_:_prefix_
This correction is also required on the example:
{{**metric*{color:#FF}s{color}:*solr.node:CONTAINER.fs.coreRoot.usableSpace}}
This is confirmed by the source code with explicit use of "metrics:" (see for
example: org.apache.solr.cloud.autoscaling.sim.SimNodeStateProvider or
org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest)
> Fix ref guide for autoscaling metric trigger
>
>
> Key: SOLR-13847
> URL: https://issues.apache.org/jira/browse/SOLR-13847
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 7.7.2, 8.2
>Reporter: ROCHETEAU Antoine
>Priority: Trivial
> Attachments: metric_trigger_documentation.patch
>
>
> Reported in the IRC channel who ask me to raise an issue,
> The documentation for the autoscaling metric trigger have an error on the
> description (it's not possible to set up a basic metric trigger with the
> current documentation).
> [https://lucene.apache.org/solr/guide/8_1/solrcloud-autoscaling-triggers.html#metric-trigger]
> metric:_group_:_prefix_ should be replaced by
> metric*{color:#ff}s{color}*:_group_:_prefix_
> This correction is also required on the example:
> {{metric*{color:#ff}s{color}*:solr.node:CONTAINER.fs.coreRoot.usableSpace}}
> This is confirmed by the source code with explicit use of "metrics:" (see
> for example: org.apache.solr.cloud.autoscaling.sim.SimNodeStateProvider or
> org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest)
--
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-13847) Fix ref guide for autoscaling metric trigger
ROCHETEAU Antoine created SOLR-13847:
Summary: Fix ref guide for autoscaling metric trigger
Key: SOLR-13847
URL: https://issues.apache.org/jira/browse/SOLR-13847
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: documentation
Affects Versions: 8.2, 7.7.2
Reporter: ROCHETEAU Antoine
Attachments: metric_trigger_documentation.patch
Reported in the IRC channel who ask me to raise an issue,
The documentation for the autoscaling metric trigger have an error on the
description (it's not possible to set up a basic metric trigger with the
current documentation).
[https://lucene.apache.org/solr/guide/8_1/solrcloud-autoscaling-triggers.html#metric-trigger]
metric:_group_:_prefix_ should be replaced by
metric*{color:#FF}s{color}*:_group_:_prefix_
This correction is also required on the example:
{{**metric*{color:#FF}s{color}:*solr.node:CONTAINER.fs.coreRoot.usableSpace}}
This is confirmed by the source code with explicit use of "metrics:" (see for
example: org.apache.solr.cloud.autoscaling.sim.SimNodeStateProvider or
org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest)
--
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-13847) Fix ref guide for autoscaling metric trigger
[
https://issues.apache.org/jira/browse/SOLR-13847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ROCHETEAU Antoine updated SOLR-13847:
-
Description:
Reported in the IRC channel who ask me to raise an issue,
The documentation for the autoscaling metric trigger have an error on the
description (it's not possible to set up a basic metric trigger with the
current documentation).
[https://lucene.apache.org/solr/guide/8_1/solrcloud-autoscaling-triggers.html#metric-trigger]
metric:_group_:_prefix_ should be replaced by
metric{color:#ff}s{color}:_group_:_prefix_
This correction is also required on the example:
{{metric{color:#ff}s{color}:solr.node:CONTAINER.fs.coreRoot.usableSpace}}
This is confirmed by the source code with explicit use of "metrics:" (see for
example: org.apache.solr.cloud.autoscaling.sim.SimNodeStateProvider or
org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest)
was:
Reported in the IRC channel who ask me to raise an issue,
The documentation for the autoscaling metric trigger have an error on the
description (it's not possible to set up a basic metric trigger with the
current documentation).
[https://lucene.apache.org/solr/guide/8_1/solrcloud-autoscaling-triggers.html#metric-trigger]
metric:_group_:_prefix_ should be replaced by
metric*{color:#ff}s{color}*:_group_:_prefix_
This correction is also required on the example:
{{metric*{color:#ff}s{color}*:solr.node:CONTAINER.fs.coreRoot.usableSpace}}
This is confirmed by the source code with explicit use of "metrics:" (see for
example: org.apache.solr.cloud.autoscaling.sim.SimNodeStateProvider or
org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest)
> Fix ref guide for autoscaling metric trigger
>
>
> Key: SOLR-13847
> URL: https://issues.apache.org/jira/browse/SOLR-13847
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 7.7.2, 8.2
>Reporter: ROCHETEAU Antoine
>Priority: Trivial
> Attachments: metric_trigger_documentation.patch
>
>
> Reported in the IRC channel who ask me to raise an issue,
> The documentation for the autoscaling metric trigger have an error on the
> description (it's not possible to set up a basic metric trigger with the
> current documentation).
> [https://lucene.apache.org/solr/guide/8_1/solrcloud-autoscaling-triggers.html#metric-trigger]
> metric:_group_:_prefix_ should be replaced by
> metric{color:#ff}s{color}:_group_:_prefix_
> This correction is also required on the example:
> {{metric{color:#ff}s{color}:solr.node:CONTAINER.fs.coreRoot.usableSpace}}
> This is confirmed by the source code with explicit use of "metrics:" (see
> for example: org.apache.solr.cloud.autoscaling.sim.SimNodeStateProvider or
> org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest)
--
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-9005) BooleanQuery.visit() incorrectly pulls subvisitors from its parent
[
https://issues.apache.org/jira/browse/LUCENE-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952207#comment-16952207
]
Michael Sokolov commented on LUCENE-9005:
-
OK. I guess -- would the patch work equally well with MUST replaced by FILTER?
> BooleanQuery.visit() incorrectly pulls subvisitors from its parent
> --
>
> Key: LUCENE-9005
> URL: https://issues.apache.org/jira/browse/LUCENE-9005
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-9005.patch
>
>
> BooleanQuery.visit() calls getSubVisitor once for each of its clause sets;
> however, this sub visitor is called on the passed-in visitor, which means
> that sub clauses get attached to its parent, rather than a visitor for that
> particular BQ.
> To illustrate, consider the following nested BooleanQuery: ("a b" (+c +d %e
> f)); we have a top-level disjunction query containing one phrase query
> (essentially a conjunction), and one boolean query containing both MUST,
> FILTER and SHOULD clauses. When visiting, the top level query will pull a
> SHOULD subvisitor, and pass both queries into it. The phrase query will pull
> a MUST subvisitor and all its two terms. The nested boolean will pull a
> MUST, and FILTER and a SHOULD; but these are all attached to the parent
> SHOULD visitor - in particular, the MUST and FILTER clauses will end up being
> attached to this SHOULD visitor, and be mis-interpreted as a disjunction.
> To fix this, BQ should first pull a MUST visitor and visit its MUST clauses
> using this visitor; SHOULD, FILTER and MUST_NOT clauses should then be pulled
> from this top-level MUST visitor.
--
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-13846) PreemptiveBasicAuthClientBuilderFactory use of static code blocks makes it unreliable in tests
[
https://issues.apache.org/jira/browse/SOLR-13846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952199#comment-16952199
]
Chris M. Hostetter commented on SOLR-13846:
---
the really weird thing here, is that both of the tests that currently use
PreemptiveBasicAuthClientBuilderFactory use the exact same user:pass
combination, so even if the static initialization is bleeding over from one
test to the other, it seems like they should still pass
Which means something else wonky is happening here.
> PreemptiveBasicAuthClientBuilderFactory use of static code blocks makes it
> unreliable in tests
> --
>
> Key: SOLR-13846
> URL: https://issues.apache.org/jira/browse/SOLR-13846
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> PreemptiveBasicAuthClientBuilderFactory uses static code blocks to initialize
> global static variables in a way that makes it largely unusable in tests.
> Notably: it uses {{System.getProperty(...)}} during classloading to read
> system properties that then affect the behavior of all future instances --
> even if an individual test explicitly sets the system property in question
> before instaniating instances of this class.
> This means that if two tests that both use instances of
> PreemptiveBasicAuthClientBuilderFactory run in the same JVM, only the system
> properties set in the first test will be used by
> PreemptiveBasicAuthClientBuilderFactory in the *second* test (even those the
> system properties get reset by the test framework between runs)
> There are currently two tests using PreemptiveBasicAuthClientBuilderFactory,
> and depending on the order they run, one will fail...
> {noformat}
> $ ant test -Dtests.jvms=1
> '-Dtests.class=*.TestQueryingOnDownCollection|*.BasicAuthOnSingleNodeTest'
> -Dtests.seed=EC8FB67A91689F48 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sl -Dtests.timezone=Asia/Baghdad -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
> ...
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=BasicAuthOnSingleNodeTest -Dtests.method=basicTest
> -Dtests.seed=EC8FB67A91689F48 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sl -Dtests.timezone=Asia/Baghdad -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR 4.05s | BasicAuthOnSingleNodeTest.basicTest <<<
>[junit4]> Throwable #1:
> org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException:
> Error from server at http://127.0.0.1:37047/solr: Expected mime type
> application/octet-stream but got text/html.
>[junit4]>
>[junit4]> content="text/html;charset=utf-8"/>
>[junit4]> Error 401 Bad credentials
>[junit4]>
>[junit4]> HTTP ERROR 401
>[junit4]> Problem accessing /solr/authCollection/select. Reason:
>[junit4]> Bad credentials href="http://eclipse.org/jetty;>Powered by Jetty:// 9.4.19.v20190610
>[junit4]>
>[junit4]>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([EC8FB67A91689F48:1E7BA118D5CD927B]:0)
>[junit4]> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.processErrorsAndResponse(Http2SolrClient.java:696)
>[junit4]> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:402)
>[junit4]> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:754)
>[junit4]> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
>[junit4]> at
> org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1003)
>[junit4]> at
> org.apache.solr.security.BasicAuthOnSingleNodeTest.basicTest(BasicAuthOnSingleNodeTest.java:72)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]> at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>[junit4]> at java.base/java.lang.Thread.run(Thread.java:834)
> {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] [Created] (SOLR-13846) PreemptiveBasicAuthClientBuilderFactory use of static code blocks makes it unreliable in tests
Chris M. Hostetter created SOLR-13846:
-
Summary: PreemptiveBasicAuthClientBuilderFactory use of static
code blocks makes it unreliable in tests
Key: SOLR-13846
URL: https://issues.apache.org/jira/browse/SOLR-13846
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Chris M. Hostetter
PreemptiveBasicAuthClientBuilderFactory uses static code blocks to initialize
global static variables in a way that makes it largely unusable in tests.
Notably: it uses {{System.getProperty(...)}} during classloading to read system
properties that then affect the behavior of all future instances -- even if an
individual test explicitly sets the system property in question before
instaniating instances of this class.
This means that if two tests that both use instances of
PreemptiveBasicAuthClientBuilderFactory run in the same JVM, only the system
properties set in the first test will be used by
PreemptiveBasicAuthClientBuilderFactory in the *second* test (even those the
system properties get reset by the test framework between runs)
There are currently two tests using PreemptiveBasicAuthClientBuilderFactory,
and depending on the order they run, one will fail...
{noformat}
$ ant test -Dtests.jvms=1
'-Dtests.class=*.TestQueryingOnDownCollection|*.BasicAuthOnSingleNodeTest'
-Dtests.seed=EC8FB67A91689F48 -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=sl -Dtests.timezone=Asia/Baghdad -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
...
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=BasicAuthOnSingleNodeTest -Dtests.method=basicTest
-Dtests.seed=EC8FB67A91689F48 -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=sl -Dtests.timezone=Asia/Baghdad -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] ERROR 4.05s | BasicAuthOnSingleNodeTest.basicTest <<<
[junit4]> Throwable #1:
org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:37047/solr: Expected mime type
application/octet-stream but got text/html.
[junit4]>
[junit4]>
[junit4]> Error 401 Bad credentials
[junit4]>
[junit4]> HTTP ERROR 401
[junit4]> Problem accessing /solr/authCollection/select. Reason:
[junit4]> Bad credentialshttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.19.v20190610
[junit4]>
[junit4]>
[junit4]>at
__randomizedtesting.SeedInfo.seed([EC8FB67A91689F48:1E7BA118D5CD927B]:0)
[junit4]>at
org.apache.solr.client.solrj.impl.Http2SolrClient.processErrorsAndResponse(Http2SolrClient.java:696)
[junit4]>at
org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:402)
[junit4]>at
org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:754)
[junit4]>at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
[junit4]>at
org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1003)
[junit4]>at
org.apache.solr.security.BasicAuthOnSingleNodeTest.basicTest(BasicAuthOnSingleNodeTest.java:72)
[junit4]>at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4]>at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit4]>at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4]>at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
[junit4]>at java.base/java.lang.Thread.run(Thread.java:834)
{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
[GitHub] [lucene-solr] Ankou76ers opened a new pull request #955: Fix metric trigger example
Ankou76ers opened a new pull request #955: Fix metric trigger example URL: https://github.com/apache/lucene-solr/pull/955 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I am authorized to contribute this code to the ASF and have removed any code I do not have a license to distribute. - [ ] 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] cbuescher commented on issue #954: LUCENE-9007: MockSynonymFilter should add TypeAttribute
cbuescher commented on issue #954: LUCENE-9007: MockSynonymFilter should add TypeAttribute URL: https://github.com/apache/lucene-solr/pull/954#issuecomment-542337593 @uschindler Don't think so, I ran `ant test` for the lucene directory, didn't find any references to this test filter in the solr part. Other existing test using this filter don't seem to bother about the additional attribute. Don't know what to make about the error in the precommit check here though, any way to re-run this? 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] uschindler commented on issue #954: LUCENE-9007: MockSynonymFilter should add TypeAttribute
uschindler commented on issue #954: LUCENE-9007: MockSynonymFilter should add TypeAttribute URL: https://github.com/apache/lucene-solr/pull/954#issuecomment-542323586 Looks fine. No other test changes needed? 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] cbuescher opened a new pull request #954: LUCENE-9007: MockSynonymFilter should add TypeAttribute
cbuescher opened a new pull request #954: LUCENE-9007: MockSynonymFilter should add TypeAttribute URL: https://github.com/apache/lucene-solr/pull/954 The MockSynonymFilter should add the type TypeAttribute to the synonyms it generates in order to make it a better stand-in for the real filter in tests. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9007) MockSynonymFilter should add TypeAttribute
Christoph Büscher created LUCENE-9007: - Summary: MockSynonymFilter should add TypeAttribute Key: LUCENE-9007 URL: https://issues.apache.org/jira/browse/LUCENE-9007 Project: Lucene - Core Issue Type: Improvement Components: modules/analysis Reporter: Christoph Büscher The MockSynonymFilter should add the type TypeAttribute to the synonyms it generates in order to make it a better stand-in for the real filter in tests. -- 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-7654) Numeric terms facet yields redundant "0.0" buckets when mincount and sort specified
[
https://issues.apache.org/jira/browse/SOLR-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952117#comment-16952117
]
Munendra S N commented on SOLR-7654:
Currently, {{mincount=0}} is not supported and the request fails with explicit
error. Hence, closing this as won't fix. When mincount=0, we can revisit this
if the issue still persists
> Numeric terms facet yields redundant "0.0" buckets when mincount and sort
> specified
> ---
>
> Key: SOLR-7654
> URL: https://issues.apache.org/jira/browse/SOLR-7654
> Project: Solr
> Issue Type: Bug
> Components: Facet Module
>Affects Versions: 5.2
>Reporter: Michael Lawrence
>Priority: Major
>
> This query:
> http://localhost:8983/solr/techproducts/select?q=*:*={"facet":{"price":{"type":"terms","field":"price","sort":"index
> asc","mincount":0}}}=json
> Yields results where every bucket has value "0.0" and count "0". Dropping
> either the "mincount" parameter or "sort" parameter fixes it.
> This is using nightly build 5.3.0-2015-05-29_12-15-41 1682437 - jenkins -
> 2015-05-29 08:22:15. Apologies if this has been fixed since.
--
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-7654) Numeric terms facet yields redundant "0.0" buckets when mincount and sort specified
[
https://issues.apache.org/jira/browse/SOLR-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N resolved SOLR-7654.
Resolution: Won't Fix
> Numeric terms facet yields redundant "0.0" buckets when mincount and sort
> specified
> ---
>
> Key: SOLR-7654
> URL: https://issues.apache.org/jira/browse/SOLR-7654
> Project: Solr
> Issue Type: Bug
> Components: Facet Module
>Affects Versions: 5.2
>Reporter: Michael Lawrence
>Priority: Major
>
> This query:
> http://localhost:8983/solr/techproducts/select?q=*:*={"facet":{"price":{"type":"terms","field":"price","sort":"index
> asc","mincount":0}}}=json
> Yields results where every bucket has value "0.0" and count "0". Dropping
> either the "mincount" parameter or "sort" parameter fixes it.
> This is using nightly build 5.3.0-2015-05-29_12-15-41 1682437 - jenkins -
> 2015-05-29 08:22:15. Apologies if this has been fixed since.
--
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] dsmiley opened a new pull request #953: LUCENE-9006: WDGF catenateAll should come before parts
dsmiley opened a new pull request #953: LUCENE-9006: WDGF catenateAll should come before parts URL: https://github.com/apache/lucene-solr/pull/953 See nocommits and parent issue. The BaseTokenStreamTestCase edit was a trivial thing to ensure the primary assertTokenStreamContents gets called first. This helps during dev when there's a failure, it's more relevant to see a failure there. 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12393) ExpandComponent only calculates the score of expanded docs when sorted by score
[ https://issues.apache.org/jira/browse/SOLR-12393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N reassigned SOLR-12393: --- Assignee: Munendra S N > ExpandComponent only calculates the score of expanded docs when sorted by > score > --- > > Key: SOLR-12393 > URL: https://issues.apache.org/jira/browse/SOLR-12393 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Reporter: David Wayne Smiley >Assignee: Munendra S N >Priority: Major > Attachments: SOLR-12393.patch, SOLR-12393.patch, SOLR-12393.patch, > SOLR-12393.patch > > > If you use the ExpandComponent to show expanded docs and if you want the > score back (specified in "fl"), it will be NaN if the expanded docs are > sorted by anything other than the default score descending. -- 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-12393) ExpandComponent only calculates the score of expanded docs when sorted by score
[
https://issues.apache.org/jira/browse/SOLR-12393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952086#comment-16952086
]
Munendra S N commented on SOLR-12393:
-
[^SOLR-12393.patch]
In the latest patch, I have changed the condition so that scores are populated
when when sort = null or score desc (default). In both these cases,
TopScoreDocCollector is used which always populates the scores.
[~dsmiley]
One more thing I observed is that, {{maxScore}} is always {{NaN}} when scores
are requested. For populating {{maxScore}} in case of non-default score, we
might need to use {{MaxScoreCollector}}. In Any case, this is not handled as
part of the patch. I will create new issue for this
> ExpandComponent only calculates the score of expanded docs when sorted by
> score
> ---
>
> Key: SOLR-12393
> URL: https://issues.apache.org/jira/browse/SOLR-12393
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other
>Reporter: David Wayne Smiley
>Priority: Major
> Attachments: SOLR-12393.patch, SOLR-12393.patch, SOLR-12393.patch,
> SOLR-12393.patch
>
>
> If you use the ExpandComponent to show expanded docs and if you want the
> score back (specified in "fl"), it will be NaN if the expanded docs are
> sorted by anything other than the default score descending.
--
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-12393) ExpandComponent only calculates the score of expanded docs when sorted by score
[ https://issues.apache.org/jira/browse/SOLR-12393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N updated SOLR-12393: Status: Patch Available (was: Open) > ExpandComponent only calculates the score of expanded docs when sorted by > score > --- > > Key: SOLR-12393 > URL: https://issues.apache.org/jira/browse/SOLR-12393 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Reporter: David Wayne Smiley >Priority: Major > Attachments: SOLR-12393.patch, SOLR-12393.patch, SOLR-12393.patch, > SOLR-12393.patch > > > If you use the ExpandComponent to show expanded docs and if you want the > score back (specified in "fl"), it will be NaN if the expanded docs are > sorted by anything other than the default score descending. -- 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-8920) Reduce size of FSTs due to use of direct-addressing encoding
[ https://issues.apache.org/jira/browse/LUCENE-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952082#comment-16952082 ] Michael Sokolov commented on LUCENE-8920: - > store outputs in a parallel array This could save quite a bit when encoding array-style since then each Arc would only have flags + a single int in the graph part of the data structure, which is where the gaps are bloating things, removing output (although many arcs have no output) - can we also offload target and label into this sidecar array? Indeed, if we can make the Arc size constant it will greatly simplify the construction logic (no need for two passes to "inflate" smaller Arcs to full size. We would be adding the array reference, so there is some tradeoff, but I bet it would be net positive. > Reduce size of FSTs due to use of direct-addressing encoding > - > > Key: LUCENE-8920 > URL: https://issues.apache.org/jira/browse/LUCENE-8920 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Sokolov >Priority: Minor > Attachments: TestTermsDictRamBytesUsed.java > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Some data can lead to worst-case ~4x RAM usage due to this optimization. > Several ideas were suggested to combat this on the mailing list: > bq. I think we can improve thesituation here by tracking, per-FST instance, > the size increase we're seeing while building (or perhaps do a preliminary > pass before building) in order to decide whether to apply the encoding. > bq. we could also make the encoding a bit more efficient. For instance I > noticed that arc metadata is pretty large in some cases (in the 10-20 bytes) > which make gaps very costly. Associating each label with a dense id and > having an intermediate lookup, ie. lookup label -> id and then id->arc offset > instead of doing label->arc directly could save a lot of space in some cases? > Also it seems that we are repeating the label in the arc metadata when > array-with-gaps is used, even though it shouldn't be necessary since the > label is implicit from the address? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8932) Allow BKDReader packedIndex to be off heap
[ https://issues.apache.org/jira/browse/LUCENE-8932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Conradson updated LUCENE-8932: --- Attachment: LUCENE-8932.patch > Allow BKDReader packedIndex to be off heap > -- > > Key: LUCENE-8932 > URL: https://issues.apache.org/jira/browse/LUCENE-8932 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jack Conradson >Priority: Minor > Attachments: LUCENE-8932.patch, LUCENE-8932.patch > > > This change modifies BKDReader to read the packedIndex bytes off heap rather > than load them all on heap at a single time. > Questions for discussion: > # Should BKDReader only support packedIndex off heap? > # If not, how should the choice be made? > Using luceneutils IndexAndSearchOpenStreetMaps present the following test > results: > with -box -points (patch) > READER MB: 1.1345596313476562 > BEST M hits/sec: 73.34277344984474 > BEST QPS: 74.63011169783009 > with -box -points (original) > READER MB: 1.7249317169189453 > BEST M hits/sec: 73.77125157623486 > BEST QPS: 75.06611062353801 > with -nearest 10 -points (patch) > READER MB: 1.1345596313476562 > BEST M hits/sec: 0.013586298373879497 > BEST QPS: 1358.6298373879497 > with -nearest 10 -points (original) > READER MB: 1.7249317169189453 > BEST M hits/sec: 0.01445208197367343 > BEST QPS: 1445.208197367343 > with -box -geo3d (patch) > READER MB: 1.1345596313476562 > BEST M hits/sec: 39.84968715299074 > BEST QPS: 40.54914292796736 > with -box -geo3d (original) > READER MB: 1.7456226348876953 > BEST M hits/sec: 40.45051734329004 > BEST QPS: 41.160519101846695 -- 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-8932) Allow BKDReader packedIndex to be off heap
[ https://issues.apache.org/jira/browse/LUCENE-8932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952079#comment-16952079 ] Jack Conradson commented on LUCENE-8932: [~jpountz] Apologies for the delay. I have added a second constructor that takes both the IndexInput and a boolean for on/off-heap. The first constructor will select off-heap iff the IndexInput extends ByteBufferIndexInput. I made all tests uses a random boolean to determine whether to test on-heap or off-heap. Finally, I changed setPosition to throw an IOException as it's the API that's changing directly. > Allow BKDReader packedIndex to be off heap > -- > > Key: LUCENE-8932 > URL: https://issues.apache.org/jira/browse/LUCENE-8932 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jack Conradson >Priority: Minor > Attachments: LUCENE-8932.patch, LUCENE-8932.patch > > > This change modifies BKDReader to read the packedIndex bytes off heap rather > than load them all on heap at a single time. > Questions for discussion: > # Should BKDReader only support packedIndex off heap? > # If not, how should the choice be made? > Using luceneutils IndexAndSearchOpenStreetMaps present the following test > results: > with -box -points (patch) > READER MB: 1.1345596313476562 > BEST M hits/sec: 73.34277344984474 > BEST QPS: 74.63011169783009 > with -box -points (original) > READER MB: 1.7249317169189453 > BEST M hits/sec: 73.77125157623486 > BEST QPS: 75.06611062353801 > with -nearest 10 -points (patch) > READER MB: 1.1345596313476562 > BEST M hits/sec: 0.013586298373879497 > BEST QPS: 1358.6298373879497 > with -nearest 10 -points (original) > READER MB: 1.7249317169189453 > BEST M hits/sec: 0.01445208197367343 > BEST QPS: 1445.208197367343 > with -box -geo3d (patch) > READER MB: 1.1345596313476562 > BEST M hits/sec: 39.84968715299074 > BEST QPS: 40.54914292796736 > with -box -geo3d (original) > READER MB: 1.7456226348876953 > BEST M hits/sec: 40.45051734329004 > BEST QPS: 41.160519101846695 -- 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-8928) BKDWriter could make splitting decisions based on the actual range of values
[ https://issues.apache.org/jira/browse/LUCENE-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952042#comment-16952042 ] Michael Sokolov commented on LUCENE-8928: - > I'm curious whether that also helps the 3D field you use to filter deals Yes, it will be interesting to see! It might take us a little while, and there tend to be more "real" deals around certain times of year ... > BKDWriter could make splitting decisions based on the actual range of values > > > Key: LUCENE-8928 > URL: https://issues.apache.org/jira/browse/LUCENE-8928 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Currently BKDWriter assumes that splitting on one dimension has no effect on > values in other dimensions. While this may be ok for geo points, this is > usually not true for ranges (or geo shapes, which are ranges too). Maybe we > could get better indexing by re-computing the range of values on each > dimension before making the choice of the split dimension? -- 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] mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields
mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce
Global Feature Based Early Termination For Sorted Fields
URL: https://github.com/apache/lucene-solr/pull/923#discussion_r335021342
##
File path:
lucene/core/src/test/org/apache/lucene/search/TestGetDocValuesLeafFieldComparators.java
##
@@ -0,0 +1,105 @@
+/*
+ * 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.lucene.search;
+
+import java.io.EOFException;
+import java.util.HashSet;
+import java.util.Set;
+
+import org.apache.lucene.document.Document;
+import org.apache.lucene.document.NumericDocValuesField;
+import org.apache.lucene.index.IndexReader;
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.index.RandomIndexWriter;
+import org.apache.lucene.store.Directory;
+import org.apache.lucene.util.LuceneTestCase;
+import org.apache.lucene.util.TestUtil;
+
+public class TestGetDocValuesLeafFieldComparators extends LuceneTestCase {
+ private IndexSearcher is;
+ private IndexReader ir;
+ private Directory dir;
+ private final Sort sort = new Sort(new SortField("ndv1",
SortField.Type.LONG));
+ private Set set = new HashSet<>();
+
+ @Override
+ public void setUp() throws Exception {
+super.setUp();
+dir = newDirectory();
+RandomIndexWriter iw = new RandomIndexWriter(random(), dir);
+int numDocs = TestUtil.nextInt(random(), 5, 15);
+for (int i = 0; i < numDocs; i++) {
+ Document doc = new Document();
+ long val = TestUtil.nextLong(random(), 15, 200);
+ doc.add(new NumericDocValuesField("ndv1", val));
+ set.add(val);
+ iw.addDocument(doc);
+}
+ir = iw.getReader();
+iw.close();
+is = newSearcher(ir);
+ }
+
+ @Override
+ public void tearDown() throws Exception {
+ir.close();
+dir.close();
+super.tearDown();
+ }
+
+ public void testValues() throws Exception {
+Sort[] sortArray = new Sort[] { sort, new Sort() };
+for(int i = 0; i < sortArray.length; i++) {
+ int count = 0;
+ Query q = new MatchAllDocsQuery();
+ TopFieldCollector tdc = TopFieldCollector.create(sortArray[i], 10,
Integer.MAX_VALUE);
+ is.search(q, tdc);
+
+ assert tdc.pq instanceof FieldValueHitQueue;
+ ScoreDoc[] scoreDocs = tdc.topDocs().scoreDocs;
+
+ for (ScoreDoc scoreDoc : scoreDocs) {
+
+FieldValueHitQueue queue = (FieldValueHitQueue) tdc.pq;
+FieldComparator[] comparators = queue.getComparators();
+
+for (FieldComparator comparator : comparators) {
+ for (LeafReaderContext context : ir.leaves()) {
+try {
+ Object value =
comparator.getLeafComparator(context).getDocValue(scoreDoc.doc);
+
+ if (value instanceof Long) {
+long castedValue = (long) value;
+assertNotNull(set.contains(castedValue));
+++count;
+ } else if (value instanceof Float) {
+float castedValue = (float) value;
+assertNotNull(set.contains(castedValue));
+++count;
+ }
Review comment:
`else` throw exception to fail the 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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields
mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce
Global Feature Based Early Termination For Sorted Fields
URL: https://github.com/apache/lucene-solr/pull/923#discussion_r335016883
##
File path: lucene/core/src/java/org/apache/lucene/search/FieldValueChecker.java
##
@@ -0,0 +1,114 @@
+/*
+ * 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.lucene.search;
+
+/**
+ * Maintains bottom feature value across multiple collectors
+ */
+public class FieldValueChecker {
+ public volatile Object value;
+ public volatile int minimumDoc;
+ private FieldComparator[] fieldComparators;
Review comment:
These can be `final`?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields
mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields URL: https://github.com/apache/lucene-solr/pull/923#discussion_r335024999 ## File path: lucene/core/src/java/org/apache/lucene/search/LeafFieldComparator.java ## @@ -116,4 +116,12 @@ * obtain the current hit's score, if necessary. */ void setScorer(Scorable scorer) throws IOException; + /** Publishes feature values for the given docID + * The passed in docID values should only move ahead -- + * DocValues do not support reverse iterations. + * WARNING: Can be a costly API, especially for sorted fields + * + * @param doc docID relative to current reader + */ + T getDocValue(int doc) throws IOException; Review comment: Is this supposed to be an optional API, i.e. an impl can choose to return `null` and then the optimization we are adding here simply won't run? 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields
mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce
Global Feature Based Early Termination For Sorted Fields
URL: https://github.com/apache/lucene-solr/pull/923#discussion_r335020015
##
File path: lucene/core/src/java/org/apache/lucene/search/TopFieldCollector.java
##
@@ -130,8 +130,25 @@ public void setScorer(Scorable scorer) throws IOException
{
public void collect(int doc) throws IOException {
++totalHits;
hitsThresholdChecker.incrementHitCount();
- if (queueFull) {
-if (collectedAllCompetitiveHits || reverseMul *
comparator.compareBottom(doc) <= 0) {
+
+ Object currentValue = null;
+
+ if (fieldValueChecker != null) {
Review comment:
Hmm why do we allow a `null` `fieldValueChecker` here? Maybe we should
break out a different collector to handle the `non-null` case?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields
mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce
Global Feature Based Early Termination For Sorted Fields
URL: https://github.com/apache/lucene-solr/pull/923#discussion_r335019302
##
File path: lucene/core/src/java/org/apache/lucene/search/TopFieldCollector.java
##
@@ -130,8 +130,25 @@ public void setScorer(Scorable scorer) throws IOException
{
public void collect(int doc) throws IOException {
++totalHits;
hitsThresholdChecker.incrementHitCount();
- if (queueFull) {
-if (collectedAllCompetitiveHits || reverseMul *
comparator.compareBottom(doc) <= 0) {
+
+ Object currentValue = null;
+
+ if (fieldValueChecker != null) {
+try {
+ currentValue = comparator.getDocValue(doc);
+} catch (UnsupportedOperationException e) {
+ fieldValueChecker.disableGlobalHitCheck();
+}
+ }
+
+ boolean isHitGloballyCompetitive =
isHitGloballyCompetitive(currentValue, doc);
+
+ // There is a potential race condition here -- the hit may no longer
be competitive between the
+ // two checks. However, the tradeoff is performing the global check
twice -- which is expensive.
+ // Hence, the worst we can end up is an extra non competitive hit
+ if (queueFull || (isHitGloballyCompetitive == false)) {
Review comment:
Don't need `( .. )` around the `(isHitGloballyCompetitive == false)`.
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields
mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce
Global Feature Based Early Termination For Sorted Fields
URL: https://github.com/apache/lucene-solr/pull/923#discussion_r335019419
##
File path: lucene/core/src/java/org/apache/lucene/search/TopFieldCollector.java
##
@@ -130,8 +130,25 @@ public void setScorer(Scorable scorer) throws IOException
{
public void collect(int doc) throws IOException {
++totalHits;
hitsThresholdChecker.incrementHitCount();
- if (queueFull) {
-if (collectedAllCompetitiveHits || reverseMul *
comparator.compareBottom(doc) <= 0) {
+
+ Object currentValue = null;
+
+ if (fieldValueChecker != null) {
+try {
+ currentValue = comparator.getDocValue(doc);
+} catch (UnsupportedOperationException e) {
+ fieldValueChecker.disableGlobalHitCheck();
+}
+ }
+
+ boolean isHitGloballyCompetitive =
isHitGloballyCompetitive(currentValue, doc);
+
+ // There is a potential race condition here -- the hit may no longer
be competitive between the
+ // two checks. However, the tradeoff is performing the global check
twice -- which is expensive.
+ // Hence, the worst we can end up is an extra non competitive hit
+ if (queueFull || (isHitGloballyCompetitive == false)) {
+if (collectedAllCompetitiveHits || (isHitGloballyCompetitive ==
false ||
Review comment:
Same 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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields
mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce
Global Feature Based Early Termination For Sorted Fields
URL: https://github.com/apache/lucene-solr/pull/923#discussion_r335023015
##
File path: lucene/core/src/java/org/apache/lucene/search/FieldValueChecker.java
##
@@ -0,0 +1,114 @@
+/*
+ * 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.lucene.search;
+
+/**
+ * Maintains bottom feature value across multiple collectors
+ */
+public class FieldValueChecker {
+ public volatile Object value;
+ public volatile int minimumDoc;
+ private FieldComparator[] fieldComparators;
+ private int[] reverseMul;
+ private boolean isEnabled = true;
+
+ public FieldValueChecker(final FieldComparator[] fieldComparators, final
int[] reverseMul) {
+assert fieldComparators.length == reverseMul.length;
+
+this.fieldComparators = fieldComparators;
+this.reverseMul = reverseMul;
+ }
+
+ void disableGlobalHitCheck() {
+isEnabled = false;
+ }
+
+ boolean isBottomValuePresent() {
+if (!isEnabled) {
Review comment:
`isEnabled == false`?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields
mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce
Global Feature Based Early Termination For Sorted Fields
URL: https://github.com/apache/lucene-solr/pull/923#discussion_r335016985
##
File path: lucene/core/src/java/org/apache/lucene/search/FieldValueChecker.java
##
@@ -0,0 +1,114 @@
+/*
+ * 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.lucene.search;
+
+/**
+ * Maintains bottom feature value across multiple collectors
+ */
+public class FieldValueChecker {
+ public volatile Object value;
+ public volatile int minimumDoc;
+ private FieldComparator[] fieldComparators;
+ private int[] reverseMul;
Review comment:
`final`?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields
mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields URL: https://github.com/apache/lucene-solr/pull/923#discussion_r335016511 ## File path: lucene/CHANGES.txt ## @@ -55,6 +55,10 @@ Improvements * LUCENE-8984: MoreLikeThis MLT is biased for uncommon fields (Andy Hind via Anshum Gupta) +* LUCENE-8949: Allow LeafFieldComparators to publish Feature Values (Atri Sharma) + +* LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields (Atri Sharma) Review comment: Lower case all but the first word 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields
mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce
Global Feature Based Early Termination For Sorted Fields
URL: https://github.com/apache/lucene-solr/pull/923#discussion_r335016736
##
File path: lucene/core/src/java/org/apache/lucene/search/FieldValueChecker.java
##
@@ -0,0 +1,114 @@
+/*
+ * 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.lucene.search;
+
+/**
+ * Maintains bottom feature value across multiple collectors
+ */
+public class FieldValueChecker {
+ public volatile Object value;
+ public volatile int minimumDoc;
+ private FieldComparator[] fieldComparators;
+ private int[] reverseMul;
+ private boolean isEnabled = true;
+
+ public FieldValueChecker(final FieldComparator[] fieldComparators, final
int[] reverseMul) {
Review comment:
We don't need `final` in the arguments?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields
mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce
Global Feature Based Early Termination For Sorted Fields
URL: https://github.com/apache/lucene-solr/pull/923#discussion_r335017579
##
File path: lucene/core/src/java/org/apache/lucene/search/FieldValueChecker.java
##
@@ -0,0 +1,114 @@
+/*
+ * 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.lucene.search;
+
+/**
+ * Maintains bottom feature value across multiple collectors
+ */
+public class FieldValueChecker {
+ public volatile Object value;
+ public volatile int minimumDoc;
+ private FieldComparator[] fieldComparators;
+ private int[] reverseMul;
+ private boolean isEnabled = true;
Review comment:
Hmm rename this, e.g. maybe `enableGlobalBottomValue` or 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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields
mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce
Global Feature Based Early Termination For Sorted Fields
URL: https://github.com/apache/lucene-solr/pull/923#discussion_r335018884
##
File path: lucene/core/src/java/org/apache/lucene/search/TopFieldCollector.java
##
@@ -130,8 +130,25 @@ public void setScorer(Scorable scorer) throws IOException
{
public void collect(int doc) throws IOException {
++totalHits;
hitsThresholdChecker.incrementHitCount();
- if (queueFull) {
-if (collectedAllCompetitiveHits || reverseMul *
comparator.compareBottom(doc) <= 0) {
+
+ Object currentValue = null;
+
+ if (fieldValueChecker != null) {
+try {
+ currentValue = comparator.getDocValue(doc);
Review comment:
+1 to use benchmarks (sorting by `SORTED` so we see the penalty of the
`ordinal` -> `BytesRef` lookup, and also sorting by simpler types -- `long`,
`int`, etc.) to settle this.
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields
mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce
Global Feature Based Early Termination For Sorted Fields
URL: https://github.com/apache/lucene-solr/pull/923#discussion_r335015329
##
File path: lucene/core/src/java/org/apache/lucene/search/FieldValueChecker.java
##
@@ -0,0 +1,114 @@
+/*
+ * 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.lucene.search;
+
+/**
+ * Maintains bottom feature value across multiple collectors
+ */
+public class FieldValueChecker {
+ public volatile Object value;
+ public volatile int minimumDoc;
+ private FieldComparator[] fieldComparators;
+ private int[] reverseMul;
+ private boolean isEnabled = true;
+
+ public FieldValueChecker(final FieldComparator[] fieldComparators, final
int[] reverseMul) {
Review comment:
Don't need these `final` for arguments?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields
mikemccand commented on a change in pull request #923: LUCENE-8988: Introduce Global Feature Based Early Termination For Sorted Fields URL: https://github.com/apache/lucene-solr/pull/923#discussion_r335016397 ## File path: lucene/CHANGES.txt ## @@ -55,6 +55,10 @@ Improvements * LUCENE-8984: MoreLikeThis MLT is biased for uncommon fields (Andy Hind via Anshum Gupta) +* LUCENE-8949: Allow LeafFieldComparators to publish Feature Values (Atri Sharma) Review comment: Lower case `Feature Values`? 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] wuyunfeng edited a comment on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries
wuyunfeng edited a comment on issue #940: LUCENE-9002: Query caching leads to
absurdly slow queries
URL: https://github.com/apache/lucene-solr/pull/940#issuecomment-542227509
@jgq2008303393 I guess you maybe not get my point, compound query cache
sub-clause just because the compound query call the
`IndexSearcher#createWeight`, then the default `createWeight` cache the
sub-clause.
```
public Weight createWeight(Query query, ScoreMode scoreMode, float boost)
throws IOException {
final QueryCache queryCache = this.queryCache;
Weight weight = query.createWeight(this, scoreMode, boost);
if (scoreMode.needsScores() == false && queryCache != null) {
weight = queryCache.doCache(weight, queryCachingPolicy);
}
return weight;
}
```
If the compound query just only `createWeight` and do not cache the
sub-clause, and just cache itself, this problem maybe not happend?
```
// extra method
public Weight createWeightWithoutCache(Query query, ScoreMode scoreMode,
float boost) throws IOException {
Weight weight = query.createWeight(this, scoreMode, boost);
return weight;
}
```
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] wuyunfeng edited a comment on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries
wuyunfeng edited a comment on issue #940: LUCENE-9002: Query caching leads to
absurdly slow queries
URL: https://github.com/apache/lucene-solr/pull/940#issuecomment-542227509
@jgq2008303393 I guess you maybe not get my point, compound query cache
sub-clause just because the compound query call the
`IndexSearcher#createWeight`, then the default `createWeight` cache the
sub-clause.
```
public Weight createWeight(Query query, ScoreMode scoreMode, float boost)
throws IOException {
final QueryCache queryCache = this.queryCache;
Weight weight = query.createWeight(this, scoreMode, boost);
if (scoreMode.needsScores() == false && queryCache != null) {
weight = queryCache.doCache(weight, queryCachingPolicy);
}
return weight;
}
```
If the compound query just only `createWeight` and do not cache the
sub-clause, and just cache itself, this problem maybe not happend?
```
public Weight createWeight(Query query, ScoreMode scoreMode, float boost)
throws IOException {
Weight weight = query.createWeight(this, scoreMode, boost);
return weight;
}
```
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] wuyunfeng edited a comment on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries
wuyunfeng edited a comment on issue #940: LUCENE-9002: Query caching leads to
absurdly slow queries
URL: https://github.com/apache/lucene-solr/pull/940#issuecomment-542227509
@jgq2008303393 I guess you maybe not get my point, compound query cache
sub-clause just because the compound query call the
`IndexSearcher#createWeight`, then the default `createWeight` cache the
sub-clause.
```
public Weight createWeight(Query query, ScoreMode scoreMode, float boost)
throws IOException {
final QueryCache queryCache = this.queryCache;
Weight weight = query.createWeight(this, scoreMode, boost);
if (scoreMode.needsScores() == false && queryCache != null) {
weight = queryCache.doCache(weight, queryCachingPolicy);
}
return weight;
}
```
If the compound query just only `createWeight` and do not cache the
sub-clause, and just cache itself, this problem maybe not happend?
```
public Weight createWeightWithoutCache(Query query, ScoreMode scoreMode,
float boost) throws IOException {
Weight weight = query.createWeight(this, scoreMode, boost);
return weight;
}
```
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #913: LUCENE-8995: TopSuggestDocsCollector#collect should be able to signal rejection
mikemccand commented on a change in pull request #913: LUCENE-8995:
TopSuggestDocsCollector#collect should be able to signal rejection
URL: https://github.com/apache/lucene-solr/pull/913#discussion_r335003223
##
File path:
lucene/suggest/src/test/org/apache/lucene/search/suggest/document/TestPrefixCompletionQuery.java
##
@@ -253,6 +258,61 @@ public void testDocFiltering() throws Exception {
iw.close();
}
+ /**
+ * Test that the correct amount of documents are collected if using a
collector that also rejects documents.
+ */
+ public void testCollectorThatRejects() throws Exception {
+// use synonym analyzer to have multiple paths to same suggested document.
This mock adds "dog" as synonym for "dogs"
+Analyzer analyzer = new MockSynonymAnalyzer();
+RandomIndexWriter iw = new RandomIndexWriter(random(), dir,
iwcWithSuggestField(analyzer, "suggest_field"));
+List expectedResults = new ArrayList();
+
+for (int docCount = 10; docCount > 0; docCount--) {
+ Document document = new Document();
+ String value = "ab" + docCount + " dogs";
+ document.add(new SuggestField("suggest_field", value, docCount));
+ expectedResults.add(new Entry(value, docCount));
+ iw.addDocument(document);
+}
+
+if (rarely()) {
+ iw.commit();
+}
+
+DirectoryReader reader = iw.getReader();
+SuggestIndexSearcher indexSearcher = new SuggestIndexSearcher(reader);
+
+PrefixCompletionQuery query = new PrefixCompletionQuery(analyzer, new
Term("suggest_field", "ab"));
+int topN = 5;
+
+// use a TopSuggestDocsCollector that rejects results with duplicate docIds
+TopSuggestDocsCollector collector = new TopSuggestDocsCollector(topN,
false) {
+
+ private Set seenDocIds = new HashSet<>();
+
+ @Override
+ public boolean collect(int docID, CharSequence key, CharSequence
context, float score) throws IOException {
+ int globalDocId = docID + docBase;
+ boolean collected = false;
+ if (seenDocIds.contains(globalDocId) == false) {
+ super.collect(docID, key, context, score);
+ seenDocIds.add(globalDocId);
+ collected = true;
+ }
+ return collected;
+ }
+};
+
+indexSearcher.suggest(query, collector);
+assertSuggestions(collector.get(), expectedResults.subList(0,
topN).toArray(new Entry[0]));
+
+// TODO expecting true here, why false?
Review comment:
+1 to open a new issue for this.
Indeed, `maxAnalyzedPathsPerOutput` comment in `NRTSuggester.java` seems to
claim it's the max number of analyzed forms for a surface form (input), e.g. a
graph tokenstream would create multiple analyzed forms.
But what it seems to actually be computing, in `NRTSuggesterBuilder.java` is
actually the maximum number of unique surface forms that analyze to the same
analyzed form.
And so I think the admissibility of the search is in question -- we use this
to size the queue "properly" but it's not clear that works today?
Let's definitely open a new issue ... this stuff is hard to think about!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #913: LUCENE-8995: TopSuggestDocsCollector#collect should be able to signal rejection
mikemccand commented on a change in pull request #913: LUCENE-8995:
TopSuggestDocsCollector#collect should be able to signal rejection
URL: https://github.com/apache/lucene-solr/pull/913#discussion_r334984757
##
File path:
lucene/suggest/src/java/org/apache/lucene/search/suggest/document/TopSuggestDocsCollector.java
##
@@ -201,4 +205,27 @@ public void collect(int doc) throws IOException {
public ScoreMode scoreMode() {
return ScoreMode.COMPLETE;
}
+
+ /**
+ * returns true if the collector clearly exhausted all possibilities to
collect results
+ */
+ boolean isComplete() {
+return this.isComplete ;
+ }
+
+ /**
+ * call to signal that during collection at least one segment might have
returned incomplete results, e.g. because
+ * of too many rejections
+ */
+ void notComplete() {
Review comment:
Could we rename to `setNotComplete`?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #913: LUCENE-8995: TopSuggestDocsCollector#collect should be able to signal rejection
mikemccand commented on a change in pull request #913: LUCENE-8995:
TopSuggestDocsCollector#collect should be able to signal rejection
URL: https://github.com/apache/lucene-solr/pull/913#discussion_r334996216
##
File path:
lucene/suggest/src/test/org/apache/lucene/search/suggest/document/TestPrefixCompletionQuery.java
##
@@ -253,6 +263,123 @@ public void testDocFiltering() throws Exception {
iw.close();
}
+ /**
+ * Test that the correct amount of documents are collected if using a
collector that also rejects documents.
+ */
+ public void testCollectorThatRejects() throws Exception {
+// use synonym analyzer to have multiple paths to same suggested document.
This mock adds "dog" as synonym for "dogs"
+Analyzer analyzer = new MockSynonymAnalyzer();
+RandomIndexWriter iw = new RandomIndexWriter(random(), dir,
iwcWithSuggestField(analyzer, "suggest_field"));
+List expectedResults = new ArrayList();
+
+for (int docCount = 10; docCount > 0; docCount--) {
+ Document document = new Document();
+ String value = "ab" + docCount + " dogs";
+ document.add(new SuggestField("suggest_field", value, docCount));
+ expectedResults.add(new Entry(value, docCount));
+ iw.addDocument(document);
+}
+
+if (rarely()) {
+ iw.commit();
+}
+
+DirectoryReader reader = iw.getReader();
+SuggestIndexSearcher indexSearcher = new SuggestIndexSearcher(reader);
+
+PrefixCompletionQuery query = new PrefixCompletionQuery(analyzer, new
Term("suggest_field", "ab"));
+int topN = 5;
+
+// use a TopSuggestDocsCollector that rejects results with duplicate docIds
+TopSuggestDocsCollector collector = new TopSuggestDocsCollector(topN,
false) {
+
+ private Set seenDocIds = new HashSet<>();
+
+ @Override
+ public boolean collect(int docID, CharSequence key, CharSequence
context, float score) throws IOException {
+ int globalDocId = docID + docBase;
+ boolean collected = false;
+ if (seenDocIds.contains(globalDocId) == false) {
Review comment:
Hmm why would the suggester even send the same `docID` multiple times?
There is only one suggestion (`SuggestField`) per indexed document in this test
... maybe improve the test to assert that sometimes we reject and sometimes we
don't?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #913: LUCENE-8995: TopSuggestDocsCollector#collect should be able to signal rejection
mikemccand commented on a change in pull request #913: LUCENE-8995:
TopSuggestDocsCollector#collect should be able to signal rejection
URL: https://github.com/apache/lucene-solr/pull/913#discussion_r334986883
##
File path:
lucene/suggest/src/java/org/apache/lucene/search/suggest/document/TopSuggestDocs.java
##
@@ -105,6 +105,10 @@ public TopSuggestDocs(TotalHits totalHits,
SuggestScoreDoc[] scoreDocs, boolean
this.isComplete = isComplete;
}
+ public TopSuggestDocs(TotalHits totalHits, SuggestScoreDoc[] scoreDocs) {
Review comment:
Since the javadocs for this class are marked with the `@lucene.experimental`
tag, we are allowed to change the API even in the next dot release (8.x), so it
is not necessary to add telescoping constructors here, so we can keep only the
constructor above that takes the new `boolean isComplete`.
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #913: LUCENE-8995: TopSuggestDocsCollector#collect should be able to signal rejection
mikemccand commented on a change in pull request #913: LUCENE-8995:
TopSuggestDocsCollector#collect should be able to signal rejection
URL: https://github.com/apache/lucene-solr/pull/913#discussion_r334992844
##
File path:
lucene/suggest/src/java/org/apache/lucene/search/suggest/document/TopSuggestDocs.java
##
@@ -116,19 +133,29 @@ public TopSuggestDocs(TotalHits totalHits,
SuggestScoreDoc[] scoreDocs) {
*/
public static TopSuggestDocs merge(int topN, TopSuggestDocs[] shardHits) {
SuggestScoreDocPriorityQueue priorityQueue = new
SuggestScoreDocPriorityQueue(topN);
+boolean allComplete = true;
for (TopSuggestDocs shardHit : shardHits) {
for (SuggestScoreDoc scoreDoc : shardHit.scoreLookupDocs()) {
if (scoreDoc == priorityQueue.insertWithOverflow(scoreDoc)) {
break;
}
}
+ allComplete &= shardHit.isComplete;
}
SuggestScoreDoc[] topNResults = priorityQueue.getResults();
if (topNResults.length > 0) {
- return new TopSuggestDocs(new TotalHits(topNResults.length,
TotalHits.Relation.EQUAL_TO), topNResults);
+ return new TopSuggestDocs(new TotalHits(topNResults.length,
TotalHits.Relation.EQUAL_TO), topNResults,
+ allComplete);
} else {
return TopSuggestDocs.EMPTY;
}
}
+ /**
+ * Indicates if the list of results is complete or not. Might be
false if the {@link TopNSearcher} rejected
+ * too many of the queued results.
Review comment:
Isn't it sometimes `false` if the `TopNSearcher`'s queue filled up and it
chose not to pursue some low-scoring partial paths?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #913: LUCENE-8995: TopSuggestDocsCollector#collect should be able to signal rejection
mikemccand commented on a change in pull request #913: LUCENE-8995:
TopSuggestDocsCollector#collect should be able to signal rejection
URL: https://github.com/apache/lucene-solr/pull/913#discussion_r334994659
##
File path:
lucene/suggest/src/java/org/apache/lucene/search/suggest/document/TopSuggestDocsCollector.java
##
@@ -116,7 +118,7 @@ protected void doSetNextReader(LeafReaderContext context)
throws IOException {
* NOTE: collection at the leaf level is guaranteed to be in
* descending order of score
*/
Review comment:
Can you explain the new `boolean` return value in the javadocs 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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #913: LUCENE-8995: TopSuggestDocsCollector#collect should be able to signal rejection
mikemccand commented on a change in pull request #913: LUCENE-8995:
TopSuggestDocsCollector#collect should be able to signal rejection
URL: https://github.com/apache/lucene-solr/pull/913#discussion_r334998208
##
File path:
lucene/suggest/src/test/org/apache/lucene/search/suggest/document/TestPrefixCompletionQuery.java
##
@@ -253,6 +263,123 @@ public void testDocFiltering() throws Exception {
iw.close();
}
+ /**
+ * Test that the correct amount of documents are collected if using a
collector that also rejects documents.
+ */
+ public void testCollectorThatRejects() throws Exception {
+// use synonym analyzer to have multiple paths to same suggested document.
This mock adds "dog" as synonym for "dogs"
+Analyzer analyzer = new MockSynonymAnalyzer();
+RandomIndexWriter iw = new RandomIndexWriter(random(), dir,
iwcWithSuggestField(analyzer, "suggest_field"));
+List expectedResults = new ArrayList();
+
+for (int docCount = 10; docCount > 0; docCount--) {
+ Document document = new Document();
+ String value = "ab" + docCount + " dogs";
+ document.add(new SuggestField("suggest_field", value, docCount));
+ expectedResults.add(new Entry(value, docCount));
+ iw.addDocument(document);
+}
+
+if (rarely()) {
+ iw.commit();
+}
+
+DirectoryReader reader = iw.getReader();
+SuggestIndexSearcher indexSearcher = new SuggestIndexSearcher(reader);
+
+PrefixCompletionQuery query = new PrefixCompletionQuery(analyzer, new
Term("suggest_field", "ab"));
+int topN = 5;
+
+// use a TopSuggestDocsCollector that rejects results with duplicate docIds
+TopSuggestDocsCollector collector = new TopSuggestDocsCollector(topN,
false) {
+
+ private Set seenDocIds = new HashSet<>();
+
+ @Override
+ public boolean collect(int docID, CharSequence key, CharSequence
context, float score) throws IOException {
+ int globalDocId = docID + docBase;
+ boolean collected = false;
+ if (seenDocIds.contains(globalDocId) == false) {
+ super.collect(docID, key, context, score);
+ seenDocIds.add(globalDocId);
+ collected = true;
+ }
+ return collected;
+ }
+
+ @Override
+ protected boolean canReject() {
+return true;
+ }
+};
+
+indexSearcher.suggest(query, collector);
+TopSuggestDocs suggestions = collector.get();
+assertSuggestions(suggestions, expectedResults.subList(0,
topN).toArray(new Entry[0]));
+assertTrue(suggestions.isComplete());
Review comment:
Is it possible to concoct a full test case (invoking suggester) where
`isComplete()` returns false?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #913: LUCENE-8995: TopSuggestDocsCollector#collect should be able to signal rejection
mikemccand commented on a change in pull request #913: LUCENE-8995:
TopSuggestDocsCollector#collect should be able to signal rejection
URL: https://github.com/apache/lucene-solr/pull/913#discussion_r334997617
##
File path:
lucene/suggest/src/test/org/apache/lucene/search/suggest/document/TestTopSuggestDocs.java
##
@@ -0,0 +1,55 @@
+/*
+ * 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.lucene.search.suggest.document;
+
+import org.apache.lucene.search.TotalHits;
+import
org.apache.lucene.search.suggest.document.TopSuggestDocs.SuggestScoreDoc;
+import org.apache.lucene.util.LuceneTestCase;
+import org.apache.lucene.util.TestUtil;
+import org.junit.Test;
+
+public class TestTopSuggestDocs extends LuceneTestCase {
+
+ @Test
Review comment:
We don't use `@Test` annotations for Lucene's tests ... the test
runner/infra infers this by the name of the methods.
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8509) NGramTokenizer, TrimFilter and WordDelimiterGraphFilter in combination can produce backwards offsets
[ https://issues.apache.org/jira/browse/LUCENE-8509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951982#comment-16951982 ] David Wayne Smiley commented on LUCENE-8509: [~romseygeek] why was this option not added as a new configuration flag? This is sort of an internal implementation detail, so it's not a big deal but If it were, it'd be easier for the tests to toggle this flag. It's also disappointing to see yet another constructor arg when we already have a bit field for booleans. Also: * the CHANGES.txt claims offset adjusting is false, but actually it defaults to true. * there was no documentation change. At least the javadocs of this class which shows all the other options. > NGramTokenizer, TrimFilter and WordDelimiterGraphFilter in combination can > produce backwards offsets > > > Key: LUCENE-8509 > URL: https://issues.apache.org/jira/browse/LUCENE-8509 > Project: Lucene - Core > Issue Type: Task >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 8.0 > > Attachments: LUCENE-8509.patch, LUCENE-8509.patch > > > Discovered by an elasticsearch user and described here: > https://github.com/elastic/elasticsearch/issues/33710 > The ngram tokenizer produces tokens "a b" and " bb" (note the space at the > beginning of the second token). The WDGF takes the first token and splits it > into two, adjusting the offsets of the second token, so we get "a"[0,1] and > "b"[2,3]. The trim filter removes the leading space from the second token, > leaving offsets unchanged, so WDGF sees "bb"[1,4]; because the leading space > has already been stripped, WDGF sees no need to adjust offsets, and emits the > token as-is, resulting in the start offsets of the tokenstream being [0, 2, > 1], and the IndexWriter rejecting 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
[GitHub] [lucene-solr] wuyunfeng edited a comment on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries
wuyunfeng edited a comment on issue #940: LUCENE-9002: Query caching leads to
absurdly slow queries
URL: https://github.com/apache/lucene-solr/pull/940#issuecomment-542227509
@jgq2008303393 I guess you maybe not get my point, compound query cache
sub-clause just because the compound query call the
`IndexSearcher#createWeight`, then the default `createWeight` cache the
sub-clause.
```
public Weight createWeight(Query query, ScoreMode scoreMode, float boost)
throws IOException {
final QueryCache queryCache = this.queryCache;
Weight weight = query.createWeight(this, scoreMode, boost);
if (scoreMode.needsScores() == false && queryCache != null) {
weight = queryCache.doCache(weight, queryCachingPolicy);
}
return weight;
}
```
If the compound query just only `createWeight` and do not cache the
sub-clause, and just cache itself, this problem maybe not happend?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9006) Ensure WordDelimiterGraphFilter always emits catenateAll token early
David Wayne Smiley created LUCENE-9006: -- Summary: Ensure WordDelimiterGraphFilter always emits catenateAll token early Key: LUCENE-9006 URL: https://issues.apache.org/jira/browse/LUCENE-9006 Project: Lucene - Core Issue Type: Improvement Components: modules/analysis Reporter: David Wayne Smiley Assignee: David Wayne Smiley Ideally, the first token of WDGF is the preserveOriginal (if configured to emit), and the second should be the catenateAll (if configured to emit). The deprecated WDF does this but WDGF can sometimes put the first other token earlier when there is a non-emitted candidate sub-token. Example input "8-other" when only generateWordParts and catenateAll -- *not* generateNumberParts. WDGF internally sees the '8' but moves on. Ultimately, the "other" token and the catenated "8other" will appear at the same internal position, which by luck fools the sorter to emit "other" first. -- 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] wuyunfeng edited a comment on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries
wuyunfeng edited a comment on issue #940: LUCENE-9002: Query caching leads to
absurdly slow queries
URL: https://github.com/apache/lucene-solr/pull/940#issuecomment-542227509
@jgq2008303393 I guess you maybe not get my point, compound query cache
sub-clause just because the compound query call the
`IndexSearcher#createWeight`, then the default `createWeight` cache the
sub-clause.
```
public Weight createWeight(Query query, ScoreMode scoreMode, float boost)
throws IOException {
final QueryCache queryCache = this.queryCache;
Weight weight = query.createWeight(this, scoreMode, boost);
if (scoreMode.needsScores() == false && queryCache != null) {
weight = queryCache.doCache(weight, queryCachingPolicy);
}
return weight;
}
```
If the compound query just `createWeight` and do not cache the
sub-clause, and just cache itself, this problem maybe not happend?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] wuyunfeng edited a comment on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries
wuyunfeng edited a comment on issue #940: LUCENE-9002: Query caching leads to
absurdly slow queries
URL: https://github.com/apache/lucene-solr/pull/940#issuecomment-542227509
@jgq2008303393 I guess you don's get my point, compound query cache
sub-clause just because the compound query call the
`IndexSearcher#createWeight`, then the default `createWeight` cache the
sub-clause.
```
public Weight createWeight(Query query, ScoreMode scoreMode, float boost)
throws IOException {
final QueryCache queryCache = this.queryCache;
Weight weight = query.createWeight(this, scoreMode, boost);
if (scoreMode.needsScores() == false && queryCache != null) {
weight = queryCache.doCache(weight, queryCachingPolicy);
}
return weight;
}
```
If the compound query just `createWeight` and do not cache the
sub-clause, and just cache itself, this problem maybe not happend?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] wuyunfeng commented on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries
wuyunfeng commented on issue #940: LUCENE-9002: Query caching leads to absurdly
slow queries
URL: https://github.com/apache/lucene-solr/pull/940#issuecomment-542227509
@jgq2008303393 I guess you don's get my point, compound query cache
sub-clause just because the compound query call the
`IndexSearcher#createWeight`, then the default `createWeight` cache the
sub-clause.
```
public Weight createWeight(Query query, ScoreMode scoreMode, float boost)
throws IOException {
final QueryCache queryCache = this.queryCache;
Weight weight = query.createWeight(this, scoreMode, boost);
if (scoreMode.needsScores() == false && queryCache != null) {
weight = queryCache.doCache(weight, queryCachingPolicy);
}
return weight;
}
```
If the compound query just `createWeight` and do not cache the
sub-clause, this problem maybe not happend?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jgq2008303393 commented on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries
jgq2008303393 commented on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries URL: https://github.com/apache/lucene-solr/pull/940#issuecomment-54821 @wuyunfeng LRUQueryCache will cache compound queries a bit earlier as it explains here: https://github.com/apache/lucene-solr/blob/61a00822e78a02f14ac060dabf66c2b5053c12d7/lucene/core/src/java/org/apache/lucene/search/UsageTrackingQueryCachingPolicy.java#L113-L137 We carefully choose a default value for skipCacheFactor so that it can fit most scenarios. And only expert users need to adjust it. When LRUQueryCache skips caching, the query latency becomes very smooth. We think that it does not have much side effect for most users :） 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jgq2008303393 commented on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries
jgq2008303393 commented on issue #940: LUCENE-9002: Query caching leads to absurdly slow queries URL: https://github.com/apache/lucene-solr/pull/940#issuecomment-542190127 @jpountz Please help to merge this PR : ) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13762) Support binary values when using XMLCodec
[ https://issues.apache.org/jira/browse/SOLR-13762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951870#comment-16951870 ] Jason Gerlowski commented on SOLR-13762: Thanks Thomas, I'll take another look shortly! > Support binary values when using XMLCodec > - > > Key: SOLR-13762 > URL: https://issues.apache.org/jira/browse/SOLR-13762 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers, Response Writers, Server, SolrJ, > UpdateRequestProcessors >Affects Versions: master (9.0), 8.3 >Reporter: Thomas Wöckinger >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > As Solr can handle binary fields, it should be possible to use XML as Codec > to encode and decode 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
[GitHub] [lucene-solr] atris commented on a change in pull request #916: LUCENE-8213: Asynchronous Caching in LRUQueryCache
atris commented on a change in pull request #916: LUCENE-8213: Asynchronous
Caching in LRUQueryCache
URL: https://github.com/apache/lucene-solr/pull/916#discussion_r334905082
##
File path: lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
##
@@ -1691,4 +1964,184 @@ public void testBulkScorerLocking() throws Exception {
t.start();
t.join();
}
+
+ public void testRejectedExecution() throws IOException {
+ExecutorService service = new TestIndexSearcher.RejectingMockExecutor();
+Directory dir = newDirectory();
+final RandomIndexWriter w = new RandomIndexWriter(random(), dir);
+
+Document doc = new Document();
+StringField f = new StringField("color", "blue", Store.NO);
+doc.add(f);
+w.addDocument(doc);
+f.setStringValue("red");
+w.addDocument(doc);
+f.setStringValue("green");
+w.addDocument(doc);
+final DirectoryReader reader = w.getReader();
+
+final Query red = new TermQuery(new Term("color", "red"));
+
+IndexSearcher searcher = new IndexSearcher(reader, service);
+
+final LRUQueryCache queryCache = new LRUQueryCache(2, 10, context ->
true);
+
+searcher.setQueryCache(queryCache);
+searcher.setQueryCachingPolicy(ALWAYS_CACHE);
+
+// To ensure that failing ExecutorService still allows query to run
+// successfully
+
+searcher.search(new ConstantScoreQuery(red), 1);
+assertEquals(Collections.singletonList(red), queryCache.cachedQueries());
+
+reader.close();
+w.close();
+dir.close();
+service.shutdown();
+ }
+
+ public void testClosedReaderExecution() throws IOException {
+CountDownLatch latch = new CountDownLatch(1);
+ExecutorService service = new BlockedMockExecutor(latch);
+
+Directory dir = newDirectory();
+final RandomIndexWriter w = new RandomIndexWriter(random(), dir);
+
+for (int i = 0; i < 100; i++) {
+ Document doc = new Document();
+ StringField f = new StringField("color", "blue", Store.NO);
+ doc.add(f);
+ w.addDocument(doc);
+ f.setStringValue("red");
+ w.addDocument(doc);
+ f.setStringValue("green");
+ w.addDocument(doc);
+
+ if (i % 10 == 0) {
+w.commit();
+ }
+}
+
+final DirectoryReader reader = w.getReader();
+
+final Query red = new TermQuery(new Term("color", "red"));
+
+IndexSearcher searcher = new IndexSearcher(reader, service) {
+ @Override
+ protected LeafSlice[] slices(List leaves) {
+ArrayList slices = new ArrayList<>();
+for (LeafReaderContext ctx : leaves) {
+ slices.add(new LeafSlice(Arrays.asList(ctx)));
+}
+return slices.toArray(LeafSlice[]::new);
+ }
+};
+
+final LRUQueryCache queryCache = new LRUQueryCache(2, 10, context ->
true);
+
+searcher.setQueryCache(queryCache);
+searcher.setQueryCachingPolicy(ALWAYS_CACHE);
+
+// To ensure that failing ExecutorService still allows query to run
+// successfully
+
+ExecutorService tempService = new ThreadPoolExecutor(2, 2, 0L,
TimeUnit.MILLISECONDS,
+new LinkedBlockingQueue(),
+new NamedThreadFactory("TestLRUQueryCache"));
+
+tempService.submit(new Runnable() {
+ @Override
+ public void run() {
+try {
+ Thread.sleep(100);
+ List leaves = searcher.leafContexts;
+
+ for (LeafReaderContext leafReaderContext : leaves) {
+leafReaderContext.reader().close();
+ }
+
+ reader.close();
+} catch (Exception e) {
+ throw new RuntimeException(e.getMessage());
+}
+
+latch.countDown();
+
+ }
+});
+
+expectThrows(AlreadyClosedException.class, () -> searcher.search(new
ConstantScoreQuery(red), 1));
Review comment:
Added a test using `RejectedExecution` to simulate the case where the search
succeeds, but the caching fails. Expected behaviour is that the caching should
then be done on the caller thread and should still show cached values.
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
With regards,
Apache Git Services
-
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 issue #916: LUCENE-8213: Asynchronous Caching in LRUQueryCache
atris commented on issue #916: LUCENE-8213: Asynchronous Caching in LRUQueryCache URL: https://github.com/apache/lucene-solr/pull/916#issuecomment-542174451 @jpountz Updated, please see and let me know 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8928) BKDWriter could make splitting decisions based on the actual range of values
[ https://issues.apache.org/jira/browse/LUCENE-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951846#comment-16951846 ] Adrien Grand commented on LUCENE-8928: -- I'm curious whether that also helps the 3D field you use to filter deals [~mikemccand] [~sokolov]. > BKDWriter could make splitting decisions based on the actual range of values > > > Key: LUCENE-8928 > URL: https://issues.apache.org/jira/browse/LUCENE-8928 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Currently BKDWriter assumes that splitting on one dimension has no effect on > values in other dimensions. While this may be ok for geo points, this is > usually not true for ranges (or geo shapes, which are ranges too). Maybe we > could get better indexing by re-computing the range of values on each > dimension before making the choice of the split dimension? -- 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-8746) Make EdgeTree (aka ComponentTree) support different type of components
[
https://issues.apache.org/jira/browse/LUCENE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951845#comment-16951845
]
Adrien Grand commented on LUCENE-8746:
--
[~ivera] FYI I disabled testRandomLineEncoding which seems to fail on a regular
basis after the commits you pushed.
> Make EdgeTree (aka ComponentTree) support different type of components
> --
>
> Key: LUCENE-8746
> URL: https://issues.apache.org/jira/browse/LUCENE-8746
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ignacio Vera
>Priority: Major
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently the class {{EdgeTree}} is a bit confusing as it is in reality a
> tree of components. The inner class {{Edge}} is the one that builds a tree of
> edges which is used by Polygon2D and Line2D to represent their structure.
> Here is proposed:
> 1) Create a new class called {{ComponentTree}} which is in fact the current
> {{EdgeTree}}
> 2) Modify {{EdgeTree}} to be in fact the inner class Edge
> 3) Extract a {{Component}} interface so we can have different types of
> components in the same tree. This allow us to support heterogeneous trees of
> components.
> 4) Make {{Polygon2D}} and {{Line2D}} instance of the component interface.
> 4) With this change, {{LatLonShapePolygonQuery}} and {{LatLonShapeLineQuery}}
> can be replaced with one {{LatLonShapeComponentQuery.}}
>
>
>
--
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-8746) Make EdgeTree (aka ComponentTree) support different type of components
[
https://issues.apache.org/jira/browse/LUCENE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951842#comment-16951842
]
ASF subversion and git services commented on LUCENE-8746:
-
Commit 8378be83b3fc0ac33566c08f0b760023fcf9b08c in lucene-solr's branch
refs/heads/branch_8x from Adrien Grand
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8378be8 ]
LUCENE-8746: Disable testRandomLineEncoding for now.
> Make EdgeTree (aka ComponentTree) support different type of components
> --
>
> Key: LUCENE-8746
> URL: https://issues.apache.org/jira/browse/LUCENE-8746
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ignacio Vera
>Priority: Major
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently the class {{EdgeTree}} is a bit confusing as it is in reality a
> tree of components. The inner class {{Edge}} is the one that builds a tree of
> edges which is used by Polygon2D and Line2D to represent their structure.
> Here is proposed:
> 1) Create a new class called {{ComponentTree}} which is in fact the current
> {{EdgeTree}}
> 2) Modify {{EdgeTree}} to be in fact the inner class Edge
> 3) Extract a {{Component}} interface so we can have different types of
> components in the same tree. This allow us to support heterogeneous trees of
> components.
> 4) Make {{Polygon2D}} and {{Line2D}} instance of the component interface.
> 4) With this change, {{LatLonShapePolygonQuery}} and {{LatLonShapeLineQuery}}
> can be replaced with one {{LatLonShapeComponentQuery.}}
>
>
>
--
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-13677) All Metrics Gauges should be unregistered by the objects that registered them
[
https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951819#comment-16951819
]
Andrzej Bialecki commented on SOLR-13677:
-
I wasn't sure what was the state of various branches so I created a new one,
with the latest patch from Noble: {{jira/solr-13677-final}} and I started
fixing the issues from review.
> All Metrics Gauges should be unregistered by the objects that registered them
> -
>
> Key: SOLR-13677
> URL: https://issues.apache.org/jira/browse/SOLR-13677
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Reporter: Noble Paul
>Assignee: Andrzej Bialecki
>Priority: Blocker
> Fix For: 8.3
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> The life cycle of Metrics producers are managed by the core (mostly). So, if
> the lifecycle of the object is different from that of the core itself, these
> objects will never be unregistered from the metrics registry. This will lead
> to memory leaks
--
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-9005) BooleanQuery.visit() incorrectly pulls subvisitors from its parent
[
https://issues.apache.org/jira/browse/LUCENE-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951768#comment-16951768
]
Alan Woodward commented on LUCENE-9005:
---
You can rewrite a BQ with a single optional clause to insert a top-level MUST
clause with the same effect: OR(term1) is the same as just +(term1), so adding
the extra visitor has no effect in this case; the same is true of MUST_NOT or
FILTER, so we don't need to check for FILTER clauses specially - (+term1
%filter) is the same as (+term1 +(%filter)) and adding the extra level doesn't
change the semantics of the query.
> BooleanQuery.visit() incorrectly pulls subvisitors from its parent
> --
>
> Key: LUCENE-9005
> URL: https://issues.apache.org/jira/browse/LUCENE-9005
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-9005.patch
>
>
> BooleanQuery.visit() calls getSubVisitor once for each of its clause sets;
> however, this sub visitor is called on the passed-in visitor, which means
> that sub clauses get attached to its parent, rather than a visitor for that
> particular BQ.
> To illustrate, consider the following nested BooleanQuery: ("a b" (+c +d %e
> f)); we have a top-level disjunction query containing one phrase query
> (essentially a conjunction), and one boolean query containing both MUST,
> FILTER and SHOULD clauses. When visiting, the top level query will pull a
> SHOULD subvisitor, and pass both queries into it. The phrase query will pull
> a MUST subvisitor and all its two terms. The nested boolean will pull a
> MUST, and FILTER and a SHOULD; but these are all attached to the parent
> SHOULD visitor - in particular, the MUST and FILTER clauses will end up being
> attached to this SHOULD visitor, and be mis-interpreted as a disjunction.
> To fix this, BQ should first pull a MUST visitor and visit its MUST clauses
> using this visitor; SHOULD, FILTER and MUST_NOT clauses should then be pulled
> from this top-level MUST visitor.
--
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-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951766#comment-16951766 ] Ishan Chattopadhyaya commented on SOLR-13677: - bq. I hope to be able to look at this tomorrow. If other stuff intervenes then I won't be able to work on this until Monday next week. Hi [~ab], could you please get a chance to look at this? > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Assignee: Andrzej Bialecki >Priority: Blocker > Fix For: 8.3 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- 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-13834) ZkController#getSolrCloudManager() creates a new instance of ZkStateReader
[ https://issues.apache.org/jira/browse/SOLR-13834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya resolved SOLR-13834. - Fix Version/s: 8.3 Resolution: Fixed Thanks [~claygoddard]! Hopefully, Solr community will benefit more from your expertise in times to come. > ZkController#getSolrCloudManager() creates a new instance of ZkStateReader > -- > > Key: SOLR-13834 > URL: https://issues.apache.org/jira/browse/SOLR-13834 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.3 > > Time Spent: 10m > Remaining Estimate: 0h > > It should be reusing the existing ZkStateReader instance . Multiple > ZkStateReader instance have different visibility to the ZK state and cause > race conditions -- 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-13834) ZkController#getSolrCloudManager() creates a new instance of ZkStateReader
[ https://issues.apache.org/jira/browse/SOLR-13834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951761#comment-16951761 ] ASF subversion and git services commented on SOLR-13834: Commit f882d9ab9bc80b7a562e41e36345ae25c540244e in lucene-solr's branch refs/heads/branch_8_3 from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f882d9a ] SOLR-13834: ZkController#getSolrCloudManager() now uses the same ZkStateReader instance instead of instantiating a new one ZkController#getSolrCloudManager() created a new instance of ZkStateReader, thereby causing mismatch in the visibility of the cluster state and, as a result, undesired race conditions. > ZkController#getSolrCloudManager() creates a new instance of ZkStateReader > -- > > Key: SOLR-13834 > URL: https://issues.apache.org/jira/browse/SOLR-13834 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Ishan Chattopadhyaya >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It should be reusing the existing ZkStateReader instance . Multiple > ZkStateReader instance have different visibility to the ZK state and cause > race conditions -- 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-8920) Reduce size of FSTs due to use of direct-addressing encoding
[ https://issues.apache.org/jira/browse/LUCENE-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951755#comment-16951755 ] Adrien Grand commented on LUCENE-8920: -- I was thinking we could store outputs in a parallel array, ordered by their associated label. When looking up a label, the FST could give us the index of the associated output? > Reduce size of FSTs due to use of direct-addressing encoding > - > > Key: LUCENE-8920 > URL: https://issues.apache.org/jira/browse/LUCENE-8920 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Sokolov >Priority: Minor > Attachments: TestTermsDictRamBytesUsed.java > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Some data can lead to worst-case ~4x RAM usage due to this optimization. > Several ideas were suggested to combat this on the mailing list: > bq. I think we can improve thesituation here by tracking, per-FST instance, > the size increase we're seeing while building (or perhaps do a preliminary > pass before building) in order to decide whether to apply the encoding. > bq. we could also make the encoding a bit more efficient. For instance I > noticed that arc metadata is pretty large in some cases (in the 10-20 bytes) > which make gaps very costly. Associating each label with a dense id and > having an intermediate lookup, ie. lookup label -> id and then id->arc offset > instead of doing label->arc directly could save a lot of space in some cases? > Also it seems that we are repeating the label in the arc metadata when > array-with-gaps is used, even though it shouldn't be necessary since the > label is implicit from the address? -- 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-13793) HTTPSolrCall makes cascading calls even when all replicas are down for a collection
[
https://issues.apache.org/jira/browse/SOLR-13793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya updated SOLR-13793:
Fix Version/s: 8.3
Resolution: Fixed
Status: Resolved (was: Patch Available)
Thanks [~keshareenv], [~munendrasn]!
> HTTPSolrCall makes cascading calls even when all replicas are down for a
> collection
> ---
>
> Key: SOLR-13793
> URL: https://issues.apache.org/jira/browse/SOLR-13793
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 6.6, master (9.0)
>Reporter: Kesharee Nandan Vishwakarma
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13793.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> REMOTEQUERY action in HTTPSolrCall ends up making too many cascading
> remoteQuery calls when all all the replicas of a collection are in down
> state.
> This results in increase in thread count, unresponsive solr nodes and
> eventually node (one's which have this collection) going out of live nodes.
> *Example scenario*: Consider a cluster with 3 nodes(solr1, solrw1,
> solr-overseer1). A collection is present on solr1, solrw1 but both replicas
> are in down state. When a search request is made to solr-overseer1, since
> replica is not present locally a remote query is made to solr1 (we also
> consider inactive slices/coreUrls), solr1 also doesn't see an active replica
> present locally, it forwards to solrw1, again solrw1 will forward request to
> solr1. This goes on till both of solr1, solrw1 become unresponsive. Attached
> logs for this.
> This is happening because we are considering [inactive
> slices|https://github.com/apache/lucene-solr/blob/68fa249034ba8b273955f20097700dc2fbb7a800/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L913
> ], [inactive coreUrl|
> https://github.com/apache/lucene-solr/blob/68fa249034ba8b273955f20097700dc2fbb7a800/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L929]
> while forwarding requests to nodes.
> *Steps to reproduce*:
> # Bring down all replicas of a collection but ensure nodes containing them
> are up
> # Make any search call to any of solr nodes for this collection.
>
> *Possible fixes*:
> # Ensure we select only active slices/coreUrls before making remote queries
> # Put a limit on cascading calls probably limit to number of replicas
>
> {noformat}
> solrw1_1 |
> solrw1_1 | 2019-09-24 09:35:14.458 ERROR (qtp762152757-8772) [ ]
> o.a.s.s.HttpSolrCall null:org.apache.solr.common.SolrException: Error trying
> to proxy request for url: http://solr1:8983/solr/kg3/select
> solrw1_1 |at
> org.apache.solr.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:660)
> solrw1_1 |at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:514)
> solrw1_1 |at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
> solrw1_1 |at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
> solrw1_1 |at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
> solrw1_1 |at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> solrw1_1 |at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> solrw1_1 |at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> solrw1_1 |at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> solrw1_1 |at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> solrw1_1 |at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
> solrw1_1
[jira] [Commented] (SOLR-13793) HTTPSolrCall makes cascading calls even when all replicas are down for a collection
[
https://issues.apache.org/jira/browse/SOLR-13793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951752#comment-16951752
]
ASF subversion and git services commented on SOLR-13793:
Commit 43303111fe8e2236cc021a6803f2b29bbd99e183 in lucene-solr's branch
refs/heads/branch_8_3 from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4330311 ]
SOLR-13793: Limiting number of forwards to total replicas in collection to
avoid deadly forwarding loops
> HTTPSolrCall makes cascading calls even when all replicas are down for a
> collection
> ---
>
> Key: SOLR-13793
> URL: https://issues.apache.org/jira/browse/SOLR-13793
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 6.6, master (9.0)
>Reporter: Kesharee Nandan Vishwakarma
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-13793.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> REMOTEQUERY action in HTTPSolrCall ends up making too many cascading
> remoteQuery calls when all all the replicas of a collection are in down
> state.
> This results in increase in thread count, unresponsive solr nodes and
> eventually node (one's which have this collection) going out of live nodes.
> *Example scenario*: Consider a cluster with 3 nodes(solr1, solrw1,
> solr-overseer1). A collection is present on solr1, solrw1 but both replicas
> are in down state. When a search request is made to solr-overseer1, since
> replica is not present locally a remote query is made to solr1 (we also
> consider inactive slices/coreUrls), solr1 also doesn't see an active replica
> present locally, it forwards to solrw1, again solrw1 will forward request to
> solr1. This goes on till both of solr1, solrw1 become unresponsive. Attached
> logs for this.
> This is happening because we are considering [inactive
> slices|https://github.com/apache/lucene-solr/blob/68fa249034ba8b273955f20097700dc2fbb7a800/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L913
> ], [inactive coreUrl|
> https://github.com/apache/lucene-solr/blob/68fa249034ba8b273955f20097700dc2fbb7a800/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L929]
> while forwarding requests to nodes.
> *Steps to reproduce*:
> # Bring down all replicas of a collection but ensure nodes containing them
> are up
> # Make any search call to any of solr nodes for this collection.
>
> *Possible fixes*:
> # Ensure we select only active slices/coreUrls before making remote queries
> # Put a limit on cascading calls probably limit to number of replicas
>
> {noformat}
> solrw1_1 |
> solrw1_1 | 2019-09-24 09:35:14.458 ERROR (qtp762152757-8772) [ ]
> o.a.s.s.HttpSolrCall null:org.apache.solr.common.SolrException: Error trying
> to proxy request for url: http://solr1:8983/solr/kg3/select
> solrw1_1 |at
> org.apache.solr.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:660)
> solrw1_1 |at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:514)
> solrw1_1 |at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
> solrw1_1 |at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
> solrw1_1 |at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
> solrw1_1 |at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> solrw1_1 |at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> solrw1_1 |at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> solrw1_1 |at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> solrw1_1 |at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> solrw1_1 |at
>
[jira] [Commented] (SOLR-13793) HTTPSolrCall makes cascading calls even when all replicas are down for a collection
[
https://issues.apache.org/jira/browse/SOLR-13793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951751#comment-16951751
]
ASF subversion and git services commented on SOLR-13793:
Commit 46df93ced48796ce1471473c920eb418abe6cefe in lucene-solr's branch
refs/heads/branch_8x from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=46df93c ]
SOLR-13793: Limiting number of forwards to total replicas in collection to
avoid deadly forwarding loops
> HTTPSolrCall makes cascading calls even when all replicas are down for a
> collection
> ---
>
> Key: SOLR-13793
> URL: https://issues.apache.org/jira/browse/SOLR-13793
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 6.6, master (9.0)
>Reporter: Kesharee Nandan Vishwakarma
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-13793.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> REMOTEQUERY action in HTTPSolrCall ends up making too many cascading
> remoteQuery calls when all all the replicas of a collection are in down
> state.
> This results in increase in thread count, unresponsive solr nodes and
> eventually node (one's which have this collection) going out of live nodes.
> *Example scenario*: Consider a cluster with 3 nodes(solr1, solrw1,
> solr-overseer1). A collection is present on solr1, solrw1 but both replicas
> are in down state. When a search request is made to solr-overseer1, since
> replica is not present locally a remote query is made to solr1 (we also
> consider inactive slices/coreUrls), solr1 also doesn't see an active replica
> present locally, it forwards to solrw1, again solrw1 will forward request to
> solr1. This goes on till both of solr1, solrw1 become unresponsive. Attached
> logs for this.
> This is happening because we are considering [inactive
> slices|https://github.com/apache/lucene-solr/blob/68fa249034ba8b273955f20097700dc2fbb7a800/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L913
> ], [inactive coreUrl|
> https://github.com/apache/lucene-solr/blob/68fa249034ba8b273955f20097700dc2fbb7a800/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L929]
> while forwarding requests to nodes.
> *Steps to reproduce*:
> # Bring down all replicas of a collection but ensure nodes containing them
> are up
> # Make any search call to any of solr nodes for this collection.
>
> *Possible fixes*:
> # Ensure we select only active slices/coreUrls before making remote queries
> # Put a limit on cascading calls probably limit to number of replicas
>
> {noformat}
> solrw1_1 |
> solrw1_1 | 2019-09-24 09:35:14.458 ERROR (qtp762152757-8772) [ ]
> o.a.s.s.HttpSolrCall null:org.apache.solr.common.SolrException: Error trying
> to proxy request for url: http://solr1:8983/solr/kg3/select
> solrw1_1 |at
> org.apache.solr.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:660)
> solrw1_1 |at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:514)
> solrw1_1 |at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
> solrw1_1 |at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
> solrw1_1 |at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
> solrw1_1 |at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> solrw1_1 |at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> solrw1_1 |at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> solrw1_1 |at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> solrw1_1 |at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> solrw1_1 |at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> solrw1_1 |at
>
