[jira] [Commented] (SOLR-6741) IPv6 Field Type
[ https://issues.apache.org/jira/browse/SOLR-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978969#comment-16978969 ] Dale Richardson commented on SOLR-6741: --- Still awaiting approval of SOLR-13260. > IPv6 Field Type > --- > > Key: SOLR-6741 > URL: https://issues.apache.org/jira/browse/SOLR-6741 > Project: Solr > Issue Type: Improvement >Reporter: Lloyd Ramey >Priority: Major > Labels: gsoc2019, mentor > Attachments: SOLR-6741.patch > > > It would be nice if Solr had a field type which could be used to index IPv6 > data and supported efficient range queries. -- 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] epugh commented on issue #1019: SOLR-13947 stream plugin documentation
epugh commented on issue #1019: SOLR-13947 stream plugin documentation URL: https://github.com/apache/lucene-solr/pull/1019#issuecomment-556856091 This PR has extra commits that should be in SOLR-13947. Going to redo. 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] epugh closed pull request #1019: SOLR-13947 stream plugin documentation
epugh closed pull request #1019: SOLR-13947 stream plugin documentation URL: https://github.com/apache/lucene-solr/pull/1019 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] [Resolved] (SOLR-12993) Split the state.json into 2. a small frequently modified data + a large unmodified data
[ https://issues.apache.org/jira/browse/SOLR-12993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-12993. --- Resolution: Abandoned > Split the state.json into 2. a small frequently modified data + a large > unmodified data > --- > > Key: SOLR-12993 > URL: https://issues.apache.org/jira/browse/SOLR-12993 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Priority: Major > > The new design is posted here > https://docs.google.com/document/d/1AZyiRA_bRhAWkUM1Nj5kg__xpPM9Fd_iwHhYazG38xI/edit# -- 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-13951) Avoid replica state updates to state.json
[ https://issues.apache.org/jira/browse/SOLR-13951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-13951: - Assignee: Noble Paul > Avoid replica state updates to state.json > -- > > Key: SOLR-13951 > URL: https://issues.apache.org/jira/browse/SOLR-13951 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > This can dramatically improve the scalability of Solr and minimize load on > Overseer > See this doc for details > https://docs.google.com/document/d/1FoPVxiVrbfoSpMqZZRGjBy_jrLI26qhWwUO_aQQ0KRQ/edit?usp=sharing -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-13951) Avoid replica state updates to state.json
Noble Paul created SOLR-13951: - Summary: Avoid replica state updates to state.json Key: SOLR-13951 URL: https://issues.apache.org/jira/browse/SOLR-13951 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul This can dramatically improve the scalability of Solr and minimize load on Overseer See this doc for details https://docs.google.com/document/d/1FoPVxiVrbfoSpMqZZRGjBy_jrLI26qhWwUO_aQQ0KRQ/edit?usp=sharing -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] andyvuong commented on a change in pull request #1023: SOLR-13950: Fix getLeaderRetry swallowing interrupt in ZkStateReader
andyvuong commented on a change in pull request #1023: SOLR-13950: Fix
getLeaderRetry swallowing interrupt in ZkStateReader
URL: https://github.com/apache/lucene-solr/pull/1023#discussion_r348849610
##
File path: solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java
##
@@ -968,7 +968,10 @@ public Replica getLeaderRetry(String collection, String
shard, int timeout) thro
}
return false;
});
-} catch (TimeoutException | InterruptedException e) {
+} catch (InterruptedException e) {
+ Thread.currentThread().interrupt();
+ throw e;
Review comment:
Thanks @tflobbe for the review - I agree and updated
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] tflobbe commented on a change in pull request #1023: SOLR-13950: Fix getLeaderRetry swallowing interrupt in ZkStateReader
tflobbe commented on a change in pull request #1023: SOLR-13950: Fix
getLeaderRetry swallowing interrupt in ZkStateReader
URL: https://github.com/apache/lucene-solr/pull/1023#discussion_r348846517
##
File path: solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java
##
@@ -968,7 +968,10 @@ public Replica getLeaderRetry(String collection, String
shard, int timeout) thro
}
return false;
});
-} catch (TimeoutException | InterruptedException e) {
+} catch (InterruptedException e) {
+ Thread.currentThread().interrupt();
+ throw e;
Review comment:
And BTW, I'm +1 with letting it bubble up
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] tflobbe commented on a change in pull request #1023: SOLR-13950: Fix getLeaderRetry swallowing interrupt in ZkStateReader
tflobbe commented on a change in pull request #1023: SOLR-13950: Fix
getLeaderRetry swallowing interrupt in ZkStateReader
URL: https://github.com/apache/lucene-solr/pull/1023#discussion_r348845903
##
File path: solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java
##
@@ -968,7 +968,10 @@ public Replica getLeaderRetry(String collection, String
shard, int timeout) thro
}
return false;
});
-} catch (TimeoutException | InterruptedException e) {
+} catch (InterruptedException e) {
+ Thread.currentThread().interrupt();
+ throw e;
Review comment:
I guess if we are going to throw the `InterruptedException` anyway then why
catch it?
The options in my mind are either not catch `InterruptedException` at all,
or catch it, mark the thread as interrupted and then throw SolrException
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-13822) Isolated Classloading from packages
[
https://issues.apache.org/jira/browse/SOLR-13822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978838#comment-16978838
]
ASF subversion and git services commented on SOLR-13822:
Commit f98555854cbdb9d396c34a93fde9c1610df74882 in lucene-solr's branch
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f985558 ]
SOLR-13822: Bug fixs and tests for URP loading
> Isolated Classloading from packages
> ---
>
> Key: SOLR-13822
> URL: https://issues.apache.org/jira/browse/SOLR-13822
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13822.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Design is here:
> [https://docs.google.com/document/d/15b3m3i3NFDKbhkhX_BN0MgvPGZaBj34TKNF2-UNC3U8/edit?ts=5d86a8ad#]
>
> main features:
> * A new file for packages definition (/packages.json) in ZK
> * Public APIs to edit/read the file
> * The APIs are registered at {{/api/cluster/package}}
> * Classes can be loaded from the package classloader using the
> {{:}} 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] (SOLR-13950) ZkStateReader’s getLeaderRetry method swallowed InterruptedException
[ https://issues.apache.org/jira/browse/SOLR-13950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Vuong updated SOLR-13950: -- Description: ZkStateReader’s getLeaderRetry(String collection, String shard, int timeout) swallows the InterruptedException and doesn’t interrupt the current thread despite declaring throws InterruptedException. This small patch calls Thread.currentThread().interrupt() and passes the InterruptedException up. was:ZkStateReader’s getLeaderRetry(String collection, String shard, int timeout) swallows the InterruptedException and doesn’t interrupt the current thread despite declaring throws InterruptedException. > ZkStateReader’s getLeaderRetry method swallowed InterruptedException > > > Key: SOLR-13950 > URL: https://issues.apache.org/jira/browse/SOLR-13950 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: master (9.0), 8.3 >Reporter: Andy Vuong >Priority: Minor > Fix For: master (9.0) > > Time Spent: 10m > Remaining Estimate: 0h > > ZkStateReader’s getLeaderRetry(String collection, String shard, int timeout) > swallows the InterruptedException and doesn’t interrupt the current thread > despite declaring throws InterruptedException. > > This small patch calls Thread.currentThread().interrupt() and passes the > InterruptedException up. -- 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] andyvuong opened a new pull request #1023: SOLR-13950: Fix getLeaderRetry swallowing interrupt in ZkStateReader
andyvuong opened a new pull request #1023: SOLR-13950: Fix getLeaderRetry swallowing interrupt in ZkStateReader URL: https://github.com/apache/lucene-solr/pull/1023 # Description InterruptedException is being swallowed in ZkStateReader’s getLeaderRetry method # Solution Catch InterruptedException separately, interrupt current thread, and throw # Tests No tests added but ran and got a passing test suite locally # 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. - [x] 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
[jira] [Created] (SOLR-13950) ZkStateReader’s getLeaderRetry method swallowed InterruptedException
Andy Vuong created SOLR-13950: - Summary: ZkStateReader’s getLeaderRetry method swallowed InterruptedException Key: SOLR-13950 URL: https://issues.apache.org/jira/browse/SOLR-13950 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: SolrJ Affects Versions: 8.3, master (9.0) Reporter: Andy Vuong Fix For: master (9.0) ZkStateReader’s getLeaderRetry(String collection, String shard, int timeout) swallows the InterruptedException and doesn’t interrupt the current thread despite declaring throws InterruptedException. -- 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-11746) numeric fields need better error handling for prefix/wildcard syntax -- consider uniform support for "foo:* == foo:[* TO *]"
[
https://issues.apache.org/jira/browse/SOLR-11746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978805#comment-16978805
]
Chris M. Hostetter commented on SOLR-11746:
---
i'm ashamed to admit that i thought this fix had been committed long ago ...
i'm not sure why i dropped the ball, let alone why i focused on FieldType
instead of just NumericFieldType. If i had to second guess myself i'm assuming
it's because I didn't think there was any risk in putting the prefix->range
delegation in FieldType and it would generally be an improvement for any Impl?
but i have no strong feelings on it either way.
bq. ... {{DocValuesFieldExistsQuery}} ...
yeah, i don't remember if that existed at the time, but it seems like the the
choice to use that should be left up to the individual impl's of getRangeQuery
as an optimization choice? ... ie: it would be a shame to have {{foo:*}} be
treated as special directly in FieldType (or NumericFieldType) and use
{{DocValuesFieldExistsQuery}} if foo has docValues, but not do the same if the
user sends in {{foo:[\* TO \*]}}
please feel free to take this issue see it to completely.
> numeric fields need better error handling for prefix/wildcard syntax --
> consider uniform support for "foo:* == foo:[* TO *]"
>
>
> Key: SOLR-11746
> URL: https://issues.apache.org/jira/browse/SOLR-11746
> Project: Solr
> Issue Type: Improvement
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-11746.patch, SOLR-11746.patch
>
>
> On the solr-user mailing list, Torsten Krah pointed out that with Trie
> numeric fields, query syntax such as {{foo_d:\*}} has been functionality
> equivilent to {{foo_d:\[\* TO \*]}} and asked why this was not also supported
> for Point based numeric fields.
> The fact that this type of syntax works (for {{indexed="true"}} Trie fields)
> appears to have been an (untested, undocumented) fluke of Trie fields given
> that they use indexed terms for the (encoded) numeric terms and inherit the
> default implementation of {{FieldType.getPrefixQuery}} which produces a
> prefix query against the {{""}} (empty string) term.
> (Note that this syntax has aparently _*never*_ worked for Trie fields with
> {{indexed="false" docValues="true"}} )
> In general, we should assess the behavior users attempt a prefix/wildcard
> syntax query against numeric fields, as currently the behavior is largely
> non-sensical: prefix/wildcard syntax frequently match no docs w/o any sort
> of error, and the aformentioned {{numeric_field:*}} behaves inconsistently
> between points/trie fields and between indexed/docValued trie fields.
--
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-11746) numeric fields need better error handling for prefix/wildcard syntax -- consider uniform support for "foo:* == foo:[* TO *]"
[
https://issues.apache.org/jira/browse/SOLR-11746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978796#comment-16978796
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-11746:
--
Does this make sense to do this in FieldType? or should it be in the
NumericFieldType?
{noformat}
public Query getPrefixQuery(QParser parser, SchemaField sf, String termStr) {
+if ("".equals(termStr)) {
+ return getRangeQuery(parser, sf, null, null, true, true);
+}
{noformat}
Don't know if this was available when you wrote the patch, but there is a
{{DocValuesFieldExistsQuery}} which we could use now if dv=true
> numeric fields need better error handling for prefix/wildcard syntax --
> consider uniform support for "foo:* == foo:[* TO *]"
>
>
> Key: SOLR-11746
> URL: https://issues.apache.org/jira/browse/SOLR-11746
> Project: Solr
> Issue Type: Improvement
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-11746.patch, SOLR-11746.patch
>
>
> On the solr-user mailing list, Torsten Krah pointed out that with Trie
> numeric fields, query syntax such as {{foo_d:\*}} has been functionality
> equivilent to {{foo_d:\[\* TO \*]}} and asked why this was not also supported
> for Point based numeric fields.
> The fact that this type of syntax works (for {{indexed="true"}} Trie fields)
> appears to have been an (untested, undocumented) fluke of Trie fields given
> that they use indexed terms for the (encoded) numeric terms and inherit the
> default implementation of {{FieldType.getPrefixQuery}} which produces a
> prefix query against the {{""}} (empty string) term.
> (Note that this syntax has aparently _*never*_ worked for Trie fields with
> {{indexed="false" docValues="true"}} )
> In general, we should assess the behavior users attempt a prefix/wildcard
> syntax query against numeric fields, as currently the behavior is largely
> non-sensical: prefix/wildcard syntax frequently match no docs w/o any sort
> of error, and the aformentioned {{numeric_field:*}} behaves inconsistently
> between points/trie fields and between indexed/docValued trie fields.
--
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-13946) SpellCheckCollatorTest.testEstimatedHitCounts reproducing failure seed
[
https://issues.apache.org/jira/browse/SOLR-13946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-13946:
--
Attachment: SOLR-13946.patch
Assignee: Chris M. Hostetter
Status: Open (was: Open)
attaching a patch i've beasted 1000 times each on master and branch_8x using
(with tests.nightly=true tests.multiplier=2 and no fixed seed) w/o any failures.
i'm planning to commit & backport soon unless anyone objects.
> SpellCheckCollatorTest.testEstimatedHitCounts reproducing failure seed
> --
>
> Key: SOLR-13946
> URL: https://issues.apache.org/jira/browse/SOLR-13946
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-13946.patch
>
>
> The following seed reliably fails on branch_8x. based on the results of git
> bisect, it appears that this in some way relates to changes made in
> LUCENE-8660 (TopDocsCollectors's accuracy in reporting totalHits when dealing
> with totalHitsThreshold) even though all usage in sol should be requesting
> {{totalHitsThreshold=Integer.MAX_VALUE}}
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=SpellCheckCollatorTest -Dtests.method=testEstimatedHitCounts
> -Dtests.seed=AFA731DEE618DA14 -Dtests.multiplier=2 -Dtests.nightly=true
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ga-IE
> -Dtests.timezone=Canada/Atlantic -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR 0.36s | SpellCheckCollatorTest.testEstimatedHitCounts <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: Exception during
> query
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([AFA731DEE618DA14:9E1C8FEB4327CAC4]:0)
>[junit4]> at
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:1001)
>[junit4]> at
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:961)
>[junit4]> at
> org.apache.solr.spelling.SpellCheckCollatorTest.testEstimatedHitCounts(SpellCheckCollatorTest.java:569)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
>[junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED:
> xpath=//lst[@name='spellcheck']/lst[@name='collations']/lst[@name='collation']/long[@name='hits'
> and 3 <= . and . <= 13]
>[junit4]> xml response was:
>[junit4]>
>[junit4]> 0 name="QTime">2 start="0"> name="everother">1 name="startOffset">918 name="suggestion">everyother name="collations"> name="collationQuery">teststop:everyother name="hits">14 name="everother">everyother
>[junit4]>
>[junit4]> request
> was:spellcheck=true&spellcheck.dictionary=direct&spellcheck.count=1&spellcheck.collate=true&spellcheck.maxCollationTries=1&spellcheck.maxCollations=1&spellcheck.collateExtendedResults=true&qt=/spellCheckCompRH&q=teststop:everother&spellcheck.collateMaxCollectDocs=5
>[junit4]> at
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:994)
>[junit4]> ... 41 more
> {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] [Resolved] (SOLR-5344) SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to time
[ https://issues.apache.org/jira/browse/SOLR-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris M. Hostetter resolved SOLR-5344. -- Resolution: Abandoned Resolving this issue as "abandoned" and linking as superceeded by SOLR-13946 > SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to > time > > > Key: SOLR-5344 > URL: https://issues.apache.org/jira/browse/SOLR-5344 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir >Assignee: James Dyer >Priority: Major > Attachments: SOLR-5344.patch > > > Doesn't happen very often, but maybe one I can fix. I'll look into 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] ajablonski opened a new pull request #1022: CUpdate eviction behavior of cache in Solr Prometheus exporter to allow for larger clusters
ajablonski opened a new pull request #1022: CUpdate eviction behavior of cache in Solr Prometheus exporter to allow for larger clusters URL: https://github.com/apache/lucene-solr/pull/1022 Will create & attach a JIRA story after getting confirmation from listserv that we agree this is an issue. tl;dr -- for large (> 100 node) clusters, the exporter fails with "connection pool shut down" for certain nodes. Co-authored-by: Serj Krasnov # 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) - [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. - [ ] 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-13907) Cloud view tree - fixed placement
[ https://issues.apache.org/jira/browse/SOLR-13907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe updated SOLR-13907: - Fix Version/s: 8.4 master (9.0) > Cloud view tree - fixed placement > - > > Key: SOLR-13907 > URL: https://issues.apache.org/jira/browse/SOLR-13907 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Richard Goodman >Priority: Minor > Fix For: master (9.0), 8.4 > > Attachments: SOLR-13907.patch, clipping-of-tree-on-x-axis.png, > fixed-metadata-panel.png > > > The tree view on the admin UI is really helpful to get a view of the znodes > in zookeeper. We've found sometimes when troubleshooting issues that this can > become quite fickle to use when you scroll down the collections list, select > a shard leader znode, and have to scroll back up again to look at the > metadata. > This small patch forces the metadata panel to be fixed to the UI, and also > forces a horizontal scrollbar for the tree. > Screenshots show the patch applied. -- 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-13907) Cloud view tree - fixed placement
[ https://issues.apache.org/jira/browse/SOLR-13907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Eduardo Fernandez Lobbe updated SOLR-13907: - Resolution: Fixed Status: Resolved (was: Patch Available) Thanks [~GoodmanR]! > Cloud view tree - fixed placement > - > > Key: SOLR-13907 > URL: https://issues.apache.org/jira/browse/SOLR-13907 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Richard Goodman >Priority: Minor > Attachments: SOLR-13907.patch, clipping-of-tree-on-x-axis.png, > fixed-metadata-panel.png > > > The tree view on the admin UI is really helpful to get a view of the znodes > in zookeeper. We've found sometimes when troubleshooting issues that this can > become quite fickle to use when you scroll down the collections list, select > a shard leader znode, and have to scroll back up again to look at the > metadata. > This small patch forces the metadata panel to be fixed to the UI, and also > forces a horizontal scrollbar for the tree. > Screenshots show the patch applied. -- 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-13907) Cloud view tree - fixed placement
[ https://issues.apache.org/jira/browse/SOLR-13907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978674#comment-16978674 ] ASF subversion and git services commented on SOLR-13907: Commit 4a3c15f11883f5b8703445ba6ed4cfe668b5f88d in lucene-solr's branch refs/heads/branch_8x from Tomas Eduardo Fernandez Lobbe [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4a3c15f ] SOLR-13907: Cloud view tree - fixed placement > Cloud view tree - fixed placement > - > > Key: SOLR-13907 > URL: https://issues.apache.org/jira/browse/SOLR-13907 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Richard Goodman >Priority: Minor > Attachments: SOLR-13907.patch, clipping-of-tree-on-x-axis.png, > fixed-metadata-panel.png > > > The tree view on the admin UI is really helpful to get a view of the znodes > in zookeeper. We've found sometimes when troubleshooting issues that this can > become quite fickle to use when you scroll down the collections list, select > a shard leader znode, and have to scroll back up again to look at the > metadata. > This small patch forces the metadata panel to be fixed to the UI, and also > forces a horizontal scrollbar for the tree. > Screenshots show the patch applied. -- 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-13907) Cloud view tree - fixed placement
[ https://issues.apache.org/jira/browse/SOLR-13907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978672#comment-16978672 ] ASF subversion and git services commented on SOLR-13907: Commit 400514026e71de6c39f0eabb8663f7ef3e774ceb in lucene-solr's branch refs/heads/master from Tomas Eduardo Fernandez Lobbe [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4005140 ] SOLR-13907: Cloud view tree - fixed placement > Cloud view tree - fixed placement > - > > Key: SOLR-13907 > URL: https://issues.apache.org/jira/browse/SOLR-13907 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Richard Goodman >Priority: Minor > Attachments: SOLR-13907.patch, clipping-of-tree-on-x-axis.png, > fixed-metadata-panel.png > > > The tree view on the admin UI is really helpful to get a view of the znodes > in zookeeper. We've found sometimes when troubleshooting issues that this can > become quite fickle to use when you scroll down the collections list, select > a shard leader znode, and have to scroll back up again to look at the > metadata. > This small patch forces the metadata panel to be fixed to the UI, and also > forces a horizontal scrollbar for the tree. > Screenshots show the patch applied. -- 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-13945) SPLITSHARD data loss due to "rollback"
[
https://issues.apache.org/jira/browse/SOLR-13945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978661#comment-16978661
]
Andrzej Bialecki commented on SOLR-13945:
-
{quote}can you please add a comment on why repFactor>1 needs a special handling
here?
{quote}
My (limited) understanding is that the new sub-replicas are already sort of
recovered - they don't need to be recovered through peer-sync because they were
constructed with all necessary content by SolrIndexSplitter just a moment ago.
The condition to switch states of parent/sub-shards is that all sub-replicas
are recovered, and this is the case here, so there's no need to wait for it
asynchronously (by monitoring replica states in ReplicaMutator).
> SPLITSHARD data loss due to "rollback"
> --
>
> Key: SOLR-13945
> URL: https://issues.apache.org/jira/browse/SOLR-13945
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-13945.patch, SOLR-13945.patch, SOLR-13945.patch
>
>
> # As per SOLR-7673, there is a commit on the parent shard *after state
> changes* have happened, i.e. from active/construction/construction to
> inactive/active/active. Please see
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L586-L588
> # Due to SOLR-12509, there's now a cleanup/rollback method called
> "cleanupAfterFailure" in the finally block that resets the state to
> active/construction/construction. Please see:
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L657
> # When 2 is entered into due to a failure in 1, we have a situation where any
> documents that went into the subshards (because they are already active by
> now) are now lost after the parent becomes active.
> If my above understanding is correct, I am wondering:
> # Why is a commit to parent shard needed *after* the parent shard is
> inactive, subshards are now active and the split operation has completed?
> # This rollback looks very suspicious. If state of subshards is already
> active and parent is inactive, then what is the need for setting them back to
> construction? Seems like a crucial check is missing there. Also, why do we
> reset the subshard status back to construction instead of inactive? It is
> extremely misleading (and, frankly, ridiculous) for any external clusterstate
> monitoring tools to see the subshards to go from CONSTRUCTION to ACTIVE to
> CONSTRUCTION and then the subshard disappearing.
--
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-9042) Refactor TopGroups.merge tests
[
https://issues.apache.org/jira/browse/LUCENE-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diego Ceccarelli updated LUCENE-9042:
-
Attachment: LUCENE-9042.patch
> Refactor TopGroups.merge tests
> --
>
> Key: LUCENE-9042
> URL: https://issues.apache.org/jira/browse/LUCENE-9042
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Diego Ceccarelli
>Priority: Minor
> Attachments: LUCENE-9042.patch
>
>
> This task proposes a refactoring of the test coverage for the
> {{TopGroups.merge}} method implemented in LUCENE-9010. For now it will cover
> only 3 main cases.
> 1. Merging to empty TopGroups
> 2. Merging a TopGroups with scores and a TopGroups without scores (currently
> broken because of LUCENE-8996 bug)
> 3. Merging two TopGroups with scores.
> I'm planning to increase the coverage testing also invalid inputs but I would
> do that in a separate PR to keep the code readable.
--
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-9042) Refactor TopGroups.merge tests
[
https://issues.apache.org/jira/browse/LUCENE-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diego Ceccarelli updated LUCENE-9042:
-
Attachment: (was: LUCENE-9042.patch)
> Refactor TopGroups.merge tests
> --
>
> Key: LUCENE-9042
> URL: https://issues.apache.org/jira/browse/LUCENE-9042
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Diego Ceccarelli
>Priority: Minor
> Attachments: LUCENE-9042.patch
>
>
> This task proposes a refactoring of the test coverage for the
> {{TopGroups.merge}} method implemented in LUCENE-9010. For now it will cover
> only 3 main cases.
> 1. Merging to empty TopGroups
> 2. Merging a TopGroups with scores and a TopGroups without scores (currently
> broken because of LUCENE-8996 bug)
> 3. Merging two TopGroups with scores.
> I'm planning to increase the coverage testing also invalid inputs but I would
> do that in a separate PR to keep the code readable.
--
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-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978623#comment-16978623
]
Colvin Cowie commented on SOLR-13682:
-
Hi [~noble.paul] the change to the SolrInputDocument in this issue appears to
have caused a problem in the JavaBinCodec to materialize. I'm still looking
into what is happening, to provide some more details. I sent a message to the
mailing list, if you could take a look at it "Possible data corruption in
JavaBinCodec in Solr 8.3 during distributed update?"
Thanks
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13948) Tooltip popup for replica information in cloud view clipping
[
https://issues.apache.org/jira/browse/SOLR-13948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978600#comment-16978600
]
Gus Heck commented on SOLR-13948:
-
This appears to be modifying this section:
{code:css}
body, h1, h2, h3, h4, h5, h6, a, button, input, select, option, textarea, th,
td, div.ui-tooltip-content
{
color: #333;
font: 12px/1.6em "Lucida Grande", "DejaVu Sans", "Bitstream Vera Sans",
Verdana, Arial, sans-serif;
overflow-wrap: break-word; /* <<< modification */
}
{code}
That effects a lot of elements. Would something like:
{code:css}
body, h1, h2, h3, h4, h5, h6, a, button, input, select, option, textarea, th,
td, div.ui-tooltip-content
{
color: #333;
font: 12px/1.6em "Lucida Grande", "DejaVu Sans", "Bitstream Vera Sans",
Verdana, Arial, sans-serif;
}
div.ui-tooltip-content
{
overflow-wrap: break-word;
}
{code}
be sufficient?
> Tooltip popup for replica information in cloud view clipping
>
>
> Key: SOLR-13948
> URL: https://issues.apache.org/jira/browse/SOLR-13948
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 7.7.2
>Reporter: Richard Goodman
>Priority: Minor
> Attachments: SOLR-13948.patch, after.png, before.png
>
>
> Our replicas typically have a long name, which has never really a problem for
> us. But with the new feature in 7.7.2 _(at least for us was new than our
> previous solr version)_ when on the cloud view and looking at the status of
> collections, when hovering over a node ip and seeing the tooltip popup of the
> replica information, this information will go over the tooltip window if the
> replica name is of a certain size.
> This small patch fixes this, I've attached some screenshots of a before and
> after, as well as the patch.
--
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-13941) Tests configure Jetty differently than when running via start.jar
[
https://issues.apache.org/jira/browse/SOLR-13941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978559#comment-16978559
]
Jan Høydahl commented on SOLR-13941:
Not 100% sure, there may be legitimate uses of either, but then I guess folks
can override with an annotation if they absolutely need to? Go ahead if you
feel it is a good idea.
> Tests configure Jetty differently than when running via start.jar
> -
>
> Key: SOLR-13941
> URL: https://issues.apache.org/jira/browse/SOLR-13941
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13941.patch
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Spinoff from SOLR-13905.
> There seems to be a slightly different configuration of our servlets when
> Solr is run from command line and through Test-runner for our tests.
> This causes different behavior of {{httpRequest.getPathInfo}} and
> {{httpRequest.getServletPath()}} in the two environments, making it hard to
> depend on these in critical code paths, such as
> [SolrDispatchFilter|https://github.com/apache/lucene-solr/blob/f07998fc234c81ff956a84ee508b85f8d573ef38/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L494-L499]
> and AuditEvent.
--
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-13945) SPLITSHARD data loss due to "rollback"
[ https://issues.apache.org/jira/browse/SOLR-13945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978538#comment-16978538 ] Ishan Chattopadhyaya commented on SOLR-13945: - bq. This code section goes as far back as branch_5x and I can't say I fully understand the need for this commit here - I suspect it has something to do with buffering updates and tlog replays between parent and sub-shards, so removing it may result in other subtle data loss. [~shalin], any ideas, please? > SPLITSHARD data loss due to "rollback" > -- > > Key: SOLR-13945 > URL: https://issues.apache.org/jira/browse/SOLR-13945 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-13945.patch, SOLR-13945.patch, SOLR-13945.patch > > > # As per SOLR-7673, there is a commit on the parent shard *after state > changes* have happened, i.e. from active/construction/construction to > inactive/active/active. Please see > https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L586-L588 > # Due to SOLR-12509, there's now a cleanup/rollback method called > "cleanupAfterFailure" in the finally block that resets the state to > active/construction/construction. Please see: > https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L657 > # When 2 is entered into due to a failure in 1, we have a situation where any > documents that went into the subshards (because they are already active by > now) are now lost after the parent becomes active. > If my above understanding is correct, I am wondering: > # Why is a commit to parent shard needed *after* the parent shard is > inactive, subshards are now active and the split operation has completed? > # This rollback looks very suspicious. If state of subshards is already > active and parent is inactive, then what is the need for setting them back to > construction? Seems like a crucial check is missing there. Also, why do we > reset the subshard status back to construction instead of inactive? It is > extremely misleading (and, frankly, ridiculous) for any external clusterstate > monitoring tools to see the subshards to go from CONSTRUCTION to ACTIVE to > CONSTRUCTION and then the subshard disappearing. -- 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-13945) SPLITSHARD data loss due to "rollback"
[
https://issues.apache.org/jira/browse/SOLR-13945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978536#comment-16978536
]
Ishan Chattopadhyaya commented on SOLR-13945:
-
Thanks for your patch. +1 to Yonik's suggestion. We really need that for this
500 line method, which is so hard to grasp!
bq. Please try the patch that I attached just now.
I think we should add a defensive check at the beginning of your cleanup
method, on the lines of: if both subshards are active, don't do anything and
bail out.
{code}
+ if (repFactor > 1) {
+t = timings.sub("finalCommit");
+ocmh.commit(results, slice.get(), parentShardLeader);
+t.stop();
+ }
{code}
Also, can you please add a comment on why repFactor>1 needs a special handling
here?
> SPLITSHARD data loss due to "rollback"
> --
>
> Key: SOLR-13945
> URL: https://issues.apache.org/jira/browse/SOLR-13945
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-13945.patch, SOLR-13945.patch, SOLR-13945.patch
>
>
> # As per SOLR-7673, there is a commit on the parent shard *after state
> changes* have happened, i.e. from active/construction/construction to
> inactive/active/active. Please see
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L586-L588
> # Due to SOLR-12509, there's now a cleanup/rollback method called
> "cleanupAfterFailure" in the finally block that resets the state to
> active/construction/construction. Please see:
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L657
> # When 2 is entered into due to a failure in 1, we have a situation where any
> documents that went into the subshards (because they are already active by
> now) are now lost after the parent becomes active.
> If my above understanding is correct, I am wondering:
> # Why is a commit to parent shard needed *after* the parent shard is
> inactive, subshards are now active and the split operation has completed?
> # This rollback looks very suspicious. If state of subshards is already
> active and parent is inactive, then what is the need for setting them back to
> construction? Seems like a crucial check is missing there. Also, why do we
> reset the subshard status back to construction instead of inactive? It is
> extremely misleading (and, frankly, ridiculous) for any external clusterstate
> monitoring tools to see the subshards to go from CONSTRUCTION to ACTIVE to
> CONSTRUCTION and then the subshard disappearing.
--
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-13941) Tests configure Jetty differently than when running via start.jar
[
https://issues.apache.org/jira/browse/SOLR-13941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978522#comment-16978522
]
Uwe Schindler commented on SOLR-13941:
--
Hi Jan,
thanks! Should I add the forbiddenapis entries for getPathInfo() and
getServletPath()?
> Tests configure Jetty differently than when running via start.jar
> -
>
> Key: SOLR-13941
> URL: https://issues.apache.org/jira/browse/SOLR-13941
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13941.patch
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Spinoff from SOLR-13905.
> There seems to be a slightly different configuration of our servlets when
> Solr is run from command line and through Test-runner for our tests.
> This causes different behavior of {{httpRequest.getPathInfo}} and
> {{httpRequest.getServletPath()}} in the two environments, making it hard to
> depend on these in critical code paths, such as
> [SolrDispatchFilter|https://github.com/apache/lucene-solr/blob/f07998fc234c81ff956a84ee508b85f8d573ef38/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L494-L499]
> and AuditEvent.
--
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-13945) SPLITSHARD data loss due to "rollback"
[ https://issues.apache.org/jira/browse/SOLR-13945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978520#comment-16978520 ] Yonik Seeley commented on SOLR-13945: - It would be great if we could capture what is currently understood about the overall split strategy here in code comments (unless it already is and I'm missing it?) perhaps at the top of SplitShardCmd since it is the top-level coordinator for a split? > SPLITSHARD data loss due to "rollback" > -- > > Key: SOLR-13945 > URL: https://issues.apache.org/jira/browse/SOLR-13945 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-13945.patch, SOLR-13945.patch, SOLR-13945.patch > > > # As per SOLR-7673, there is a commit on the parent shard *after state > changes* have happened, i.e. from active/construction/construction to > inactive/active/active. Please see > https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L586-L588 > # Due to SOLR-12509, there's now a cleanup/rollback method called > "cleanupAfterFailure" in the finally block that resets the state to > active/construction/construction. Please see: > https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L657 > # When 2 is entered into due to a failure in 1, we have a situation where any > documents that went into the subshards (because they are already active by > now) are now lost after the parent becomes active. > If my above understanding is correct, I am wondering: > # Why is a commit to parent shard needed *after* the parent shard is > inactive, subshards are now active and the split operation has completed? > # This rollback looks very suspicious. If state of subshards is already > active and parent is inactive, then what is the need for setting them back to > construction? Seems like a crucial check is missing there. Also, why do we > reset the subshard status back to construction instead of inactive? It is > extremely misleading (and, frankly, ridiculous) for any external clusterstate > monitoring tools to see the subshards to go from CONSTRUCTION to ACTIVE to > CONSTRUCTION and then the subshard disappearing. -- 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-13907) Cloud view tree - fixed placement
[ https://issues.apache.org/jira/browse/SOLR-13907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Goodman updated SOLR-13907: --- Status: Patch Available (was: Open) > Cloud view tree - fixed placement > - > > Key: SOLR-13907 > URL: https://issues.apache.org/jira/browse/SOLR-13907 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Richard Goodman >Priority: Minor > Attachments: SOLR-13907.patch, clipping-of-tree-on-x-axis.png, > fixed-metadata-panel.png > > > The tree view on the admin UI is really helpful to get a view of the znodes > in zookeeper. We've found sometimes when troubleshooting issues that this can > become quite fickle to use when you scroll down the collections list, select > a shard leader znode, and have to scroll back up again to look at the > metadata. > This small patch forces the metadata panel to be fixed to the UI, and also > forces a horizontal scrollbar for the tree. > Screenshots show the patch applied. -- 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-13948) Tooltip popup for replica information in cloud view clipping
[ https://issues.apache.org/jira/browse/SOLR-13948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Goodman updated SOLR-13948: --- Attachment: SOLR-13948.patch > Tooltip popup for replica information in cloud view clipping > > > Key: SOLR-13948 > URL: https://issues.apache.org/jira/browse/SOLR-13948 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 7.7.2 >Reporter: Richard Goodman >Priority: Minor > Attachments: SOLR-13948.patch, after.png, before.png > > > Our replicas typically have a long name, which has never really a problem for > us. But with the new feature in 7.7.2 _(at least for us was new than our > previous solr version)_ when on the cloud view and looking at the status of > collections, when hovering over a node ip and seeing the tooltip popup of the > replica information, this information will go over the tooltip window if the > replica name is of a certain size. > This small patch fixes this, I've attached some screenshots of a before and > after, as well as the patch. -- 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-13948) Tooltip popup for replica information in cloud view clipping
Richard Goodman created SOLR-13948: -- Summary: Tooltip popup for replica information in cloud view clipping Key: SOLR-13948 URL: https://issues.apache.org/jira/browse/SOLR-13948 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Admin UI Affects Versions: 7.7.2 Reporter: Richard Goodman Attachments: SOLR-13948.patch, after.png, before.png Our replicas typically have a long name, which has never really a problem for us. But with the new feature in 7.7.2 _(at least for us was new than our previous solr version)_ when on the cloud view and looking at the status of collections, when hovering over a node ip and seeing the tooltip popup of the replica information, this information will go over the tooltip window if the replica name is of a certain size. This small patch fixes this, I've attached some screenshots of a before and after, as well as the patch. -- 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-13948) Tooltip popup for replica information in cloud view clipping
[ https://issues.apache.org/jira/browse/SOLR-13948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Goodman updated SOLR-13948: --- Status: Patch Available (was: Open) > Tooltip popup for replica information in cloud view clipping > > > Key: SOLR-13948 > URL: https://issues.apache.org/jira/browse/SOLR-13948 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 7.7.2 >Reporter: Richard Goodman >Priority: Minor > Attachments: SOLR-13948.patch, after.png, before.png > > > Our replicas typically have a long name, which has never really a problem for > us. But with the new feature in 7.7.2 _(at least for us was new than our > previous solr version)_ when on the cloud view and looking at the status of > collections, when hovering over a node ip and seeing the tooltip popup of the > replica information, this information will go over the tooltip window if the > replica name is of a certain size. > This small patch fixes this, I've attached some screenshots of a before and > after, as well as the patch. -- 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-9056) Simplify BlockImpactsDocsEnum#advance
[
https://issues.apache.org/jira/browse/LUCENE-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978484#comment-16978484
]
Adrien Grand commented on LUCENE-9056:
--
Here is a run on wikibigall. I'm surprised Prefix3 and Wildcard get the best
speedups given that it only removes an increment in BlockDocsEnum#nextDoc, but
I'm taking it. :)
{noformat}
TaskQPS baseline StdDev QPS patch StdDev
Pct diff
IntNRQ 975.14 (3.3%) 968.70 (2.7%)
-0.7% ( -6% -5%)
IntervalsOrdered 23.67 (1.5%) 23.60 (1.4%)
-0.3% ( -3% -2%)
SpanNear 10.74 (1.7%) 10.71 (2.2%)
-0.3% ( -4% -3%)
Fuzzy2 80.09 (12.5%) 80.37 (12.1%)
0.3% ( -21% - 28%)
Fuzzy1 147.40 (14.1%) 148.56 (13.2%)
0.8% ( -23% - 32%)
OrHighMed 70.77 (2.7%) 71.72 (2.1%)
1.3% ( -3% -6%)
AndMedOrHighHigh 29.92 (2.3%) 30.32 (2.5%)
1.3% ( -3% -6%)
AndHighHigh 36.51 (3.3%) 37.03 (4.2%)
1.4% ( -5% -9%)
AndHighMed 92.78 (2.7%) 94.12 (3.6%)
1.5% ( -4% -8%)
SloppyPhrase 19.90 (4.3%) 20.19 (3.9%)
1.5% ( -6% - 10%)
OrHighHigh 10.15 (3.1%) 10.32 (2.5%)
1.7% ( -3% -7%)
Term 1345.29 (5.2%) 1373.69 (3.9%)
2.1% ( -6% - 11%)
AndHighOrMedMed 37.48 (2.3%) 38.34 (2.4%)
2.3% ( -2% -7%)
HighTermDayOfYearSort 40.85 (5.4%) 41.82 (4.5%)
2.4% ( -7% - 13%)
Phrase 66.19 (5.7%) 68.02 (4.6%)
2.8% ( -7% - 13%)
HighTermMonthSort 66.00 (12.0%) 68.35 (12.9%)
3.6% ( -19% - 32%)
Wildcard 99.69 (5.3%) 103.99 (4.1%)
4.3% ( -4% - 14%)
Prefix3 51.85 (11.0%) 55.76 (10.1%)
7.5% ( -12% - 32%)
{noformat}
> Simplify BlockImpactsDocsEnum#advance
> -
>
> Key: LUCENE-9056
> URL: https://issues.apache.org/jira/browse/LUCENE-9056
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a follow-up to LUCENE-9027. Now that we compute the prefix sum in
> #refillDocs, we can remove the check that we are on the last document of the
> postings list so that we should return NO_MORE_DOCS.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz opened a new pull request #1021: LUCENE-9056: Fewer conditionals in #advance.
jpountz opened a new pull request #1021: LUCENE-9056: Fewer conditionals in #advance. URL: https://github.com/apache/lucene-solr/pull/1021 I also cherry-picked LUCENE-8901 (lazy loading of freq blocks) for BlockDocsImpactsEnum. 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-9056) Simplify BlockImpactsDocsEnum#advance
Adrien Grand created LUCENE-9056: Summary: Simplify BlockImpactsDocsEnum#advance Key: LUCENE-9056 URL: https://issues.apache.org/jira/browse/LUCENE-9056 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand This is a follow-up to LUCENE-9027. Now that we compute the prefix sum in #refillDocs, we can remove the check that we are on the last document of the postings list so that we should return NO_MORE_DOCS. -- 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-13905) Make findRequestType in AuditEvent more robust
[ https://issues.apache.org/jira/browse/SOLR-13905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978471#comment-16978471 ] Jan Høydahl commented on SOLR-13905: SOLR-13941 is pushed, and it actually fixed the bug first reported in this jira. So I changed the title to do the improvements in AuditEvent. > Make findRequestType in AuditEvent more robust > -- > > Key: SOLR-13905 > URL: https://issues.apache.org/jira/browse/SOLR-13905 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Auditlogging >Affects Versions: 8.3 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.4 > > Time Spent: 10m > Remaining Estimate: 0h > > In SOLR-13941 we fixed the root cause for a NullPointer exception in > findRequestType for certain AuditEvents. > In this issue we make it even more robust and make the pattern matching more > performant at the same time as detecting some more patterns for ADMIN > requests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13013) Change export to extract DocValues in docID order
[ https://issues.apache.org/jira/browse/SOLR-13013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978467#comment-16978467 ] Jason Gerlowski commented on SOLR-13013: Chiming in late to the discussion so far. bq. I expect that it needs at least a full re-implementation of the MapWriter-parts I actually thought the FieldWriter stuff looked pretty well done. It cuts a decent bit of duplication out of those implementation classes. bq. Should there be a setting for max memory usage and if violated adjust the window size or fallback to old logic? We should definitely expose some knobs here so users can tweak performance/memory-usage for their use case. But I think adding smart-picking or auto-failover etc. is something that should be deferred to a second pass. I'm all for it, it just seems like something that'll be easier to get right once we've had this optimization out there for a bit and start getting feedback on where this does/doesn't work well. > Change export to extract DocValues in docID order > - > > Key: SOLR-13013 > URL: https://issues.apache.org/jira/browse/SOLR-13013 > Project: Solr > Issue Type: Improvement > Components: Export Writer >Affects Versions: 7.5, 8.0 >Reporter: Toke Eskildsen >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13013.patch, SOLR-13013_proof_of_concept.patch, > SOLR-13013_proof_of_concept.patch > > > The streaming export writer uses a sliding window of 30,000 documents for > paging through the result set in a given sort order. Each time a window has > been calculated, the values for the export fields are retrieved from the > underlying DocValues structures in document sort order and delivered. > The iterative DocValues API introduced in Lucene/Solr 7 does not support > random access. The current export implementation bypasses this by creating a > new DocValues-iterator for each individual value to retrieve. This slows down > export as the iterator has to seek to the given docID from start for each > value. The slowdown scales with shard size (see LUCENE-8374 for details). An > alternative is to extract the DocValues in docID-order, with re-use of > DocValues-iterators. The idea is as follows: > # Change the FieldWriters for export to re-use the DocValues-iterators if > subsequent requests are for docIDs higher than the previous ones > # Calculate the sliding window of SortDocs as usual > # Take a note of the order of the SortDocs in the sliding window > # Re-sort the SortDocs in docID-order > # Extract the DocValues to a temporary on-heap structure > # Re-sort the extracted values to the original sliding window order > Deliver the values > One big difference from the current export code is of course the need to hold > the whole sliding window scaled result set in memory. This might well be a > showstopper as there is no real limit to how large this partial result set > can be. Maybe such an optimization could be requested explicitly if the user > knows that there is enough memory? -- 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-13945) SPLITSHARD data loss due to "rollback"
[ https://issues.apache.org/jira/browse/SOLR-13945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978427#comment-16978427 ] Andrzej Bialecki commented on SOLR-13945: - Please try the patch that I attached just now. > SPLITSHARD data loss due to "rollback" > -- > > Key: SOLR-13945 > URL: https://issues.apache.org/jira/browse/SOLR-13945 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-13945.patch, SOLR-13945.patch, SOLR-13945.patch > > > # As per SOLR-7673, there is a commit on the parent shard *after state > changes* have happened, i.e. from active/construction/construction to > inactive/active/active. Please see > https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L586-L588 > # Due to SOLR-12509, there's now a cleanup/rollback method called > "cleanupAfterFailure" in the finally block that resets the state to > active/construction/construction. Please see: > https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L657 > # When 2 is entered into due to a failure in 1, we have a situation where any > documents that went into the subshards (because they are already active by > now) are now lost after the parent becomes active. > If my above understanding is correct, I am wondering: > # Why is a commit to parent shard needed *after* the parent shard is > inactive, subshards are now active and the split operation has completed? > # This rollback looks very suspicious. If state of subshards is already > active and parent is inactive, then what is the need for setting them back to > construction? Seems like a crucial check is missing there. Also, why do we > reset the subshard status back to construction instead of inactive? It is > extremely misleading (and, frankly, ridiculous) for any external clusterstate > monitoring tools to see the subshards to go from CONSTRUCTION to ACTIVE to > CONSTRUCTION and then the subshard disappearing. -- 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-13945) SPLITSHARD data loss due to "rollback"
[ https://issues.apache.org/jira/browse/SOLR-13945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-13945: Attachment: SOLR-13945.patch > SPLITSHARD data loss due to "rollback" > -- > > Key: SOLR-13945 > URL: https://issues.apache.org/jira/browse/SOLR-13945 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-13945.patch, SOLR-13945.patch, SOLR-13945.patch > > > # As per SOLR-7673, there is a commit on the parent shard *after state > changes* have happened, i.e. from active/construction/construction to > inactive/active/active. Please see > https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L586-L588 > # Due to SOLR-12509, there's now a cleanup/rollback method called > "cleanupAfterFailure" in the finally block that resets the state to > active/construction/construction. Please see: > https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L657 > # When 2 is entered into due to a failure in 1, we have a situation where any > documents that went into the subshards (because they are already active by > now) are now lost after the parent becomes active. > If my above understanding is correct, I am wondering: > # Why is a commit to parent shard needed *after* the parent shard is > inactive, subshards are now active and the split operation has completed? > # This rollback looks very suspicious. If state of subshards is already > active and parent is inactive, then what is the need for setting them back to > construction? Seems like a crucial check is missing there. Also, why do we > reset the subshard status back to construction instead of inactive? It is > extremely misleading (and, frankly, ridiculous) for any external clusterstate > monitoring tools to see the subshards to go from CONSTRUCTION to ACTIVE to > CONSTRUCTION and then the subshard disappearing. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7888) Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter parameter available in Solr
[
https://issues.apache.org/jira/browse/SOLR-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978423#comment-16978423
]
Srinivas Kallepalli edited comment on SOLR-7888 at 11/20/19 1:28 PM:
-
Hi,
I am also looking for a way to filter out the suggestions using multiple
fields. Is there a way to do that? For example I want to filter my suggestions
based on validity and product type but I can only configure one contextField in
the suggester.
Please help me out on this.
cc: [~janhoy] [~arcadius]
Thanks,
Srini.
was (Author: skallepalli):
Hi,
I am also looking for a way to filter out the suggestions using multiple
fields. Is there a way to do that? For example I want to filter my suggestions
based on validity and product type but I can only configure one contextField in
the suggester.
Please help me out on this.
Thanks,
Srini.
> Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a
> BooleanQuery filter parameter available in Solr
> --
>
> Key: SOLR-7888
> URL: https://issues.apache.org/jira/browse/SOLR-7888
> Project: Solr
> Issue Type: New Feature
> Components: Suggester
>Affects Versions: 5.2.1
>Reporter: Arcadius Ahouansou
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 5.4, 6.0
>
> Attachments: SOLR-7888-7963.patch, SOLR-7888.patch, SOLR-7888.patch
>
>
> LUCENE-6464 has introduced a very flexible lookup method that takes as
> parameter a BooleanQuery that is used for filtering results.
> This ticket is to expose that method to Solr.
> This would allow user to do:
> {code}
> /suggest?suggest=true&suggest.build=true&suggest.q=term&suggest.contextFilterQuery=contexts:tennis
> /suggest?suggest=true&suggest.build=true&suggest.q=term&suggest.contextFilterQuery=contexts:golf
> AND contexts:football
> {code}
> etc
> Given that the context filtering in currently only implemented by the
> {code}AnalyzingInfixSuggester{code} and by the
> {code}BlendedInfixSuggester{code}, this initial implementation will support
> only these 2 lookup implementations.
--
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-7888) Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter parameter available in Solr
[
https://issues.apache.org/jira/browse/SOLR-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978423#comment-16978423
]
Srinivas Kallepalli commented on SOLR-7888:
---
Hi,
I am also looking for a way to filter out the suggestions using multiple
fields. Is there a way to do that? For example I want to filter my suggestions
based on validity and product type but I can only configure one contextField in
the suggester.
Please help me out on this.
Thanks,
Srini.
> Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a
> BooleanQuery filter parameter available in Solr
> --
>
> Key: SOLR-7888
> URL: https://issues.apache.org/jira/browse/SOLR-7888
> Project: Solr
> Issue Type: New Feature
> Components: Suggester
>Affects Versions: 5.2.1
>Reporter: Arcadius Ahouansou
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 5.4, 6.0
>
> Attachments: SOLR-7888-7963.patch, SOLR-7888.patch, SOLR-7888.patch
>
>
> LUCENE-6464 has introduced a very flexible lookup method that takes as
> parameter a BooleanQuery that is used for filtering results.
> This ticket is to expose that method to Solr.
> This would allow user to do:
> {code}
> /suggest?suggest=true&suggest.build=true&suggest.q=term&suggest.contextFilterQuery=contexts:tennis
> /suggest?suggest=true&suggest.build=true&suggest.q=term&suggest.contextFilterQuery=contexts:golf
> AND contexts:football
> {code}
> etc
> Given that the context filtering in currently only implemented by the
> {code}AnalyzingInfixSuggester{code} and by the
> {code}BlendedInfixSuggester{code}, this initial implementation will support
> only these 2 lookup implementations.
--
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-13945) SPLITSHARD data loss due to "rollback"
[ https://issues.apache.org/jira/browse/SOLR-13945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978405#comment-16978405 ] Ishan Chattopadhyaya commented on SOLR-13945: - bq. Did you run this scenario on a collection with replicationFactor==1? If not, then I think there must be something else going on here. Exactly, replicationFactor was 1, hence state change was immediate. > SPLITSHARD data loss due to "rollback" > -- > > Key: SOLR-13945 > URL: https://issues.apache.org/jira/browse/SOLR-13945 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-13945.patch, SOLR-13945.patch > > > # As per SOLR-7673, there is a commit on the parent shard *after state > changes* have happened, i.e. from active/construction/construction to > inactive/active/active. Please see > https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L586-L588 > # Due to SOLR-12509, there's now a cleanup/rollback method called > "cleanupAfterFailure" in the finally block that resets the state to > active/construction/construction. Please see: > https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L657 > # When 2 is entered into due to a failure in 1, we have a situation where any > documents that went into the subshards (because they are already active by > now) are now lost after the parent becomes active. > If my above understanding is correct, I am wondering: > # Why is a commit to parent shard needed *after* the parent shard is > inactive, subshards are now active and the split operation has completed? > # This rollback looks very suspicious. If state of subshards is already > active and parent is inactive, then what is the need for setting them back to > construction? Seems like a crucial check is missing there. Also, why do we > reset the subshard status back to construction instead of inactive? It is > extremely misleading (and, frankly, ridiculous) for any external clusterstate > monitoring tools to see the subshards to go from CONSTRUCTION to ACTIVE to > CONSTRUCTION and then the subshard disappearing. -- 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-13945) SPLITSHARD data loss due to "rollback"
[
https://issues.apache.org/jira/browse/SOLR-13945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978371#comment-16978371
]
Andrzej Bialecki commented on SOLR-13945:
-
Did you run this scenario on a collection with replicationFactor==1? If not,
then I think there must be something else going on here.
The call to {{commit}} assumes the parent shard is still ACTIVE, and it should
be when repFactor > 1, because in this case the parent/sub shard states are
switched to inactive/active not in SplitShardCmd but in ReplicaMutator, and
then only *after* all replicas in the new sub-shards finished recovering and
are ACTIVE.
This doesn't seem to be the case when repFactor == 1, because that's when the
parent/sub shard states are switched immediately, and then indeed the call to
commit would produce an error. This is something that we can easily fix by
calling the commit earlier, or not treating this situation as a special case.
This code section goes as far back as branch_5x (!) and I can't say I fully
understand the need for this commit here - I suspect it has something to do
with buffering updates and tlog replays between parent and sub-shards, so
removing it may result in other subtle data loss.
> SPLITSHARD data loss due to "rollback"
> --
>
> Key: SOLR-13945
> URL: https://issues.apache.org/jira/browse/SOLR-13945
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-13945.patch, SOLR-13945.patch
>
>
> # As per SOLR-7673, there is a commit on the parent shard *after state
> changes* have happened, i.e. from active/construction/construction to
> inactive/active/active. Please see
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L586-L588
> # Due to SOLR-12509, there's now a cleanup/rollback method called
> "cleanupAfterFailure" in the finally block that resets the state to
> active/construction/construction. Please see:
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L657
> # When 2 is entered into due to a failure in 1, we have a situation where any
> documents that went into the subshards (because they are already active by
> now) are now lost after the parent becomes active.
> If my above understanding is correct, I am wondering:
> # Why is a commit to parent shard needed *after* the parent shard is
> inactive, subshards are now active and the split operation has completed?
> # This rollback looks very suspicious. If state of subshards is already
> active and parent is inactive, then what is the need for setting them back to
> construction? Seems like a crucial check is missing there. Also, why do we
> reset the subshard status back to construction instead of inactive? It is
> extremely misleading (and, frankly, ridiculous) for any external clusterstate
> monitoring tools to see the subshards to go from CONSTRUCTION to ACTIVE to
> CONSTRUCTION and then the subshard disappearing.
--
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] iverase opened a new pull request #1020: LUCENE-9055: Fixes the detection of lines crossing triangles through edge points
iverase opened a new pull request #1020: LUCENE-9055: Fixes the detection of lines crossing triangles through edge points URL: https://github.com/apache/lucene-solr/pull/1020 When a line crosses a triangle through an edge point, the crossing is not detected. 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-9055) Line2D misses crossings through triangle edge points
Ignacio Vera created LUCENE-9055: Summary: Line2D misses crossings through triangle edge points Key: LUCENE-9055 URL: https://issues.apache.org/jira/browse/LUCENE-9055 Project: Lucene - Core Issue Type: Bug Reporter: Ignacio Vera when a line crosses a triangle through an edge point, the crossing is not detected. -- 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-13905) Make findRequestType in AuditEvent more robust
[
https://issues.apache.org/jira/browse/SOLR-13905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-13905:
---
Description:
In SOLR-13941 we fixed the root cause for a NullPointer exception in
findRequestType for certain AuditEvents.
In this issue we make it even more robust and make the pattern matching more
performant at the same time as detecting some more patterns for ADMIN requests.
was:
Nullpointer exception in AuditEvent for events with HttpServletRequest as
input. Happens when {{getPathInfo()}} returns null, which was not caught by
current tests. This causes the whole request to fail, rendering the audit
service unusable.
The nullpointer is experienced in the {{findRequestType()}} method when
performing pattern match on the resource (path).
This is a regression from 8.3, caused by SOLR-13835 where we switched from
fetching the URL path from {{httpRequest.getContextPath()}} to
{{httpRequest.getPathInfo()}}. However while this method behaves well in tests
(JettyTestRunner) it returns {{null}} in production.
> Make findRequestType in AuditEvent more robust
> --
>
> Key: SOLR-13905
> URL: https://issues.apache.org/jira/browse/SOLR-13905
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Auditlogging
>Affects Versions: 8.3
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.4
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In SOLR-13941 we fixed the root cause for a NullPointer exception in
> findRequestType for certain AuditEvents.
> In this issue we make it even more robust and make the pattern matching more
> performant at the same time as detecting some more patterns for ADMIN
> requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13905) Make findRequestType in AuditEvent more robust
[
https://issues.apache.org/jira/browse/SOLR-13905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-13905:
---
Fix Version/s: (was: 8.3.1)
> Make findRequestType in AuditEvent more robust
> --
>
> Key: SOLR-13905
> URL: https://issues.apache.org/jira/browse/SOLR-13905
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Auditlogging
>Affects Versions: 8.3
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.4
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Nullpointer exception in AuditEvent for events with HttpServletRequest as
> input. Happens when {{getPathInfo()}} returns null, which was not caught by
> current tests. This causes the whole request to fail, rendering the audit
> service unusable.
> The nullpointer is experienced in the {{findRequestType()}} method when
> performing pattern match on the resource (path).
> This is a regression from 8.3, caused by SOLR-13835 where we switched from
> fetching the URL path from {{httpRequest.getContextPath()}} to
> {{httpRequest.getPathInfo()}}. However while this method behaves well in
> tests (JettyTestRunner) it returns {{null}} in production.
--
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-13905) Make findRequestType in AuditEvent more robust
[
https://issues.apache.org/jira/browse/SOLR-13905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-13905:
---
Issue Type: Improvement (was: Bug)
> Make findRequestType in AuditEvent more robust
> --
>
> Key: SOLR-13905
> URL: https://issues.apache.org/jira/browse/SOLR-13905
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Auditlogging
>Affects Versions: 8.3
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.4, 8.3.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Nullpointer exception in AuditEvent for events with HttpServletRequest as
> input. Happens when {{getPathInfo()}} returns null, which was not caught by
> current tests. This causes the whole request to fail, rendering the audit
> service unusable.
> The nullpointer is experienced in the {{findRequestType()}} method when
> performing pattern match on the resource (path).
> This is a regression from 8.3, caused by SOLR-13835 where we switched from
> fetching the URL path from {{httpRequest.getContextPath()}} to
> {{httpRequest.getPathInfo()}}. However while this method behaves well in
> tests (JettyTestRunner) it returns {{null}} in production.
--
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-13905) Make findRequestType in AuditEvent more robust
[
https://issues.apache.org/jira/browse/SOLR-13905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-13905:
---
Summary: Make findRequestType in AuditEvent more robust (was: Nullpointer
exception in AuditEvent)
> Make findRequestType in AuditEvent more robust
> --
>
> Key: SOLR-13905
> URL: https://issues.apache.org/jira/browse/SOLR-13905
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Auditlogging
>Affects Versions: 8.3
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.4, 8.3.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Nullpointer exception in AuditEvent for events with HttpServletRequest as
> input. Happens when {{getPathInfo()}} returns null, which was not caught by
> current tests. This causes the whole request to fail, rendering the audit
> service unusable.
> The nullpointer is experienced in the {{findRequestType()}} method when
> performing pattern match on the resource (path).
> This is a regression from 8.3, caused by SOLR-13835 where we switched from
> fetching the URL path from {{httpRequest.getContextPath()}} to
> {{httpRequest.getPathInfo()}}. However while this method behaves well in
> tests (JettyTestRunner) it returns {{null}} in production.
--
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-9031) UnsupportedOperationException on highlighting Interval Query
[ https://issues.apache.org/jira/browse/LUCENE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978281#comment-16978281 ] Alan Woodward commented on LUCENE-9031: --- Let's remove the `dunno y` check in `TestMatchesIterator` given that we know why now :) I think I'd break the highlighter test changes out into an entirely new test, rather than combining Interval queries with other query types - in particular, using randomization to cover everything means that we don't test all queries on every run, which makes for frustrating debugging in future when tests all pass locally and then fail when you commit because they're testing different query types. > UnsupportedOperationException on highlighting Interval Query > > > Key: LUCENE-9031 > URL: https://issues.apache.org/jira/browse/LUCENE-9031 > Project: Lucene - Core > Issue Type: Bug > Components: modules/queries >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Major > Fix For: 8.4 > > Attachments: LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch, > LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch, LUCENE-9031.patch, > LUCENE-9031.patch > > Time Spent: 3.5h > Remaining Estimate: 0h > > When UnifiedHighlighter highlights Interval Query it encounters > UnsupportedOperationException. -- 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-13941) Tests configure Jetty differently than when running via start.jar
[
https://issues.apache.org/jira/browse/SOLR-13941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved SOLR-13941.
Resolution: Fixed
> Tests configure Jetty differently than when running via start.jar
> -
>
> Key: SOLR-13941
> URL: https://issues.apache.org/jira/browse/SOLR-13941
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13941.patch
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Spinoff from SOLR-13905.
> There seems to be a slightly different configuration of our servlets when
> Solr is run from command line and through Test-runner for our tests.
> This causes different behavior of {{httpRequest.getPathInfo}} and
> {{httpRequest.getServletPath()}} in the two environments, making it hard to
> depend on these in critical code paths, such as
> [SolrDispatchFilter|https://github.com/apache/lucene-solr/blob/f07998fc234c81ff956a84ee508b85f8d573ef38/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L494-L499]
> and AuditEvent.
--
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-13941) Tests configure Jetty differently than when running via start.jar
[
https://issues.apache.org/jira/browse/SOLR-13941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-13941:
--
Assignee: Jan Høydahl (was: Uwe Schindler)
> Tests configure Jetty differently than when running via start.jar
> -
>
> Key: SOLR-13941
> URL: https://issues.apache.org/jira/browse/SOLR-13941
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13941.patch
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Spinoff from SOLR-13905.
> There seems to be a slightly different configuration of our servlets when
> Solr is run from command line and through Test-runner for our tests.
> This causes different behavior of {{httpRequest.getPathInfo}} and
> {{httpRequest.getServletPath()}} in the two environments, making it hard to
> depend on these in critical code paths, such as
> [SolrDispatchFilter|https://github.com/apache/lucene-solr/blob/f07998fc234c81ff956a84ee508b85f8d573ef38/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L494-L499]
> and AuditEvent.
--
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-13941) Tests configure Jetty differently than when running via start.jar
[
https://issues.apache.org/jira/browse/SOLR-13941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978276#comment-16978276
]
ASF subversion and git services commented on SOLR-13941:
Commit 58d5680a90c860efb1cc5fc33c3f5b8201f84fe0 in lucene-solr's branch
refs/heads/branch_8x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=58d5680 ]
SOLR-13941: Configure JettySolrRunner same as in web.xml (#1018)
(cherry picked from commit f00bcd560901ebed420c51e52fda788ae8654103)
> Tests configure Jetty differently than when running via start.jar
> -
>
> Key: SOLR-13941
> URL: https://issues.apache.org/jira/browse/SOLR-13941
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Jan Høydahl
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13941.patch
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Spinoff from SOLR-13905.
> There seems to be a slightly different configuration of our servlets when
> Solr is run from command line and through Test-runner for our tests.
> This causes different behavior of {{httpRequest.getPathInfo}} and
> {{httpRequest.getServletPath()}} in the two environments, making it hard to
> depend on these in critical code paths, such as
> [SolrDispatchFilter|https://github.com/apache/lucene-solr/blob/f07998fc234c81ff956a84ee508b85f8d573ef38/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L494-L499]
> and AuditEvent.
--
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-13941) Tests configure Jetty differently than when running via start.jar
[
https://issues.apache.org/jira/browse/SOLR-13941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978245#comment-16978245
]
ASF subversion and git services commented on SOLR-13941:
Commit f00bcd560901ebed420c51e52fda788ae8654103 in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f00bcd5 ]
SOLR-13941: Configure JettySolrRunner same as in web.xml (#1018)
> Tests configure Jetty differently than when running via start.jar
> -
>
> Key: SOLR-13941
> URL: https://issues.apache.org/jira/browse/SOLR-13941
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Jan Høydahl
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13941.patch
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Spinoff from SOLR-13905.
> There seems to be a slightly different configuration of our servlets when
> Solr is run from command line and through Test-runner for our tests.
> This causes different behavior of {{httpRequest.getPathInfo}} and
> {{httpRequest.getServletPath()}} in the two environments, making it hard to
> depend on these in critical code paths, such as
> [SolrDispatchFilter|https://github.com/apache/lucene-solr/blob/f07998fc234c81ff956a84ee508b85f8d573ef38/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L494-L499]
> and AuditEvent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy merged pull request #1018: SOLR-13941: Configure JettySolrRunner same as in web.xml
janhoy merged pull request #1018: SOLR-13941: Configure JettySolrRunner same as in web.xml URL: https://github.com/apache/lucene-solr/pull/1018 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-9027) SIMD-based decoding of postings lists
[
https://issues.apache.org/jira/browse/LUCENE-9027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978213#comment-16978213
]
Bruno Roustant commented on LUCENE-9027:
Impressive!
> SIMD-based decoding of postings lists
> -
>
> Key: LUCENE-9027
> URL: https://issues.apache.org/jira/browse/LUCENE-9027
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 8.4
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> [~rcmuir] has been mentioning the idea for quite some time that we might be
> able to write the decoding logic in such a way that Java would use SIMD
> instructions. More recently [~paul.masurel] wrote a [blog
> post|https://fulmicoton.com/posts/bitpacking/] that raises the point that
> Lucene could still do decode multiple ints at once in a single instruction by
> packing two ints in a long and we've had some discussions about what we could
> try in Lucene to speed up the decoding of postings. This made me want to look
> a bit deeper at what we could do.
> Our current decoding logic reads data in a byte[] and decodes packed integers
> from it. Unfortunately it doesn't make use of SIMD instructions and looks
> like
> [this|https://github.com/jpountz/decode-128-ints-benchmark/blob/master/src/main/java/jpountz/NaiveByteDecoder.java].
> I confirmed by looking at the generated assembly that if I take an array of
> integers and shift them all by the same number of bits then Java will use
> SIMD instructions to shift multiple integers at once. This led me to writing
> this
> [implementation|https://github.com/jpountz/decode-128-ints-benchmark/blob/master/src/main/java/jpountz/SimpleSIMDDecoder.java]
> that tries as much as possible to shift long sequences of ints by the same
> number of bits to speed up decoding. It is indeed faster than the current
> logic we have, up to about 2x faster for some numbers of bits per value.
> Currently the best
> [implementation|https://github.com/jpountz/decode-128-ints-benchmark/blob/master/src/main/java/jpountz/SIMDDecoder.java]
> I've been able to come up with combines the above idea with the idea that
> Paul mentioned in his blog that consists of emulating SIMD from Java by
> packing multiple integers into a long: 2 ints, 4 shorts or 8 bytes. It is a
> bit harder to read but gives another speedup on top of the above
> implementation.
> I have a [JMH
> benchmark|https://github.com/jpountz/decode-128-ints-benchmark/] available in
> case someone would like to play with this and maybe even come up with an even
> faster implementation. It is 2-2.5x faster than our current implementation
> for most numbers of bits per value. I'm copying results here:
> {noformat}
> * `readLongs` just reads 2*bitsPerValue longs from the ByteBuffer, it serves
> as
>a baseline.
> * `decodeNaiveFromBytes` reads a byte[] and decodes from it. This is what the
>current Lucene codec does.
> * `decodeNaiveFromLongs` decodes from longs on the fly.
> * `decodeSimpleSIMD` is a simple implementation that relies on how Java
>recognizes some patterns and uses SIMD instructions.
> * `decodeSIMD` is a more complex implementation that both relies on the C2
>compiler to generate SIMD instructions and encodes 8 bytes, 4 shorts or
>2 ints in a long in order to decompress multiple values at once.
> Benchmark (bitsPerValue) (byteOrder)
> Mode Cnt Score Error Units
> PackedIntsDecodeBenchmark.decodeNaiveFromBytes 1 LE
> thrpt5 12.912 ± 0.393 ops/us
> PackedIntsDecodeBenchmark.decodeNaiveFromBytes 1 BE
> thrpt5 12.862 ± 0.395 ops/us
> PackedIntsDecodeBenchmark.decodeNaiveFromBytes 2 LE
> thrpt5 13.040 ± 1.162 ops/us
> PackedIntsDecodeBenchmark.decodeNaiveFromBytes 2 BE
> thrpt5 13.027 ± 0.270 ops/us
> PackedIntsDecodeBenchmark.decodeNaiveFromBytes 3 LE
> thrpt5 12.409 ± 0.637 ops/us
> PackedIntsDecodeBenchmark.decodeNaiveFromBytes 3 BE
> thrpt5 12.268 ± 0.947 ops/us
> PackedIntsDecodeBenchmark.decodeNaiveFromBytes 4 LE
> thrpt5 14.177 ± 2.263 ops/us
> PackedIntsDecodeBenchmark.decodeNaiveFromBytes 4 BE
> thrpt5 11.457 ± 0.150 ops/us
> PackedIntsDecodeBenchmark.decodeNaiveFromBytes 5 LE
> thrpt5 10.988 ± 1.179 ops/us
> PackedIntsDecodeBenchmark.decodeNaiveFromBytes 5 BE
> thrpt5 11.226 ± 0.088 ops/us
> PackedIntsDecodeBenchmark.decodeNaiveFromBytes 6 LE
> thrpt5 9.791 ± 0.305 ops/us
> PackedIntsDecode
