[jira] [Updated] (LUCENE-9164) Should not consider ACE a tragedy if IW is closed
[ https://issues.apache.org/jira/browse/LUCENE-9164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-9164: Fix Version/s: (was: 8.5) 8.6 > Should not consider ACE a tragedy if IW is closed > - > > Key: LUCENE-9164 > URL: https://issues.apache.org/jira/browse/LUCENE-9164 > Project: Lucene - Core > Issue Type: Bug > Components: core/index >Affects Versions: master (9.0), 8.5, 8.4.2 >Reporter: Nhat Nguyen >Assignee: Nhat Nguyen >Priority: Major > Fix For: master (9.0), 8.6 > > Attachments: LUCENE-9164.patch, LUCENE-9164.patch > > Time Spent: 7h 20m > Remaining Estimate: 0h > > If IndexWriter is closed or being closed, AlreadyClosedException is expected. > We should not consider it a tragic event in this case. -- 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-14328) HdfsDirectory support createTempOutput
Kayne Wu created SOLR-14328: --- Summary: HdfsDirectory support createTempOutput Key: SOLR-14328 URL: https://issues.apache.org/jira/browse/SOLR-14328 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: Kayne Wu When use HdfsDirectory to build or merge large index with sorted filed n use HdfsDirectory to build or merge large index with sorted filed feature，the HdfsDirectory will throw an UnsupportedOperationException due to createTempOutput(String prefix, String suffix, IOContext context) method unrealized. -- 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] kaynewu commented on issue #1143: SOLR-14328:HdfsDirectory support createTempOutput
kaynewu commented on issue #1143: SOLR-14328:HdfsDirectory support createTempOutput URL: https://github.com/apache/lucene-solr/pull/1143#issuecomment-599191196 > @kaynewu Have you opened a JIRA issue as well for this? sorry for the late reply， I have opened a JIRA for this problem，Please check when you are convenient， thank you so much. 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] kaynewu edited a comment on issue #1143: SOLR-14328:HdfsDirectory support createTempOutput
kaynewu edited a comment on issue #1143: SOLR-14328:HdfsDirectory support createTempOutput URL: https://github.com/apache/lucene-solr/pull/1143#issuecomment-599191196 > @kaynewu Have you opened a JIRA issue as well for this? @janhoy Sorry for the late reply， I have opened a JIRA for this problem，Please check when you are convenient， thank you so much. 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] kaynewu edited a comment on issue #1143: SOLR-14328:HdfsDirectory support createTempOutput
kaynewu edited a comment on issue #1143: SOLR-14328:HdfsDirectory support createTempOutput URL: https://github.com/apache/lucene-solr/pull/1143#issuecomment-599191196 > @kaynewu Have you opened a JIRA issue as well for this? @janhoy Sorry for the late reply， I have opened a JIRA for this problem， https://issues.apache.org/jira/browse/SOLR-14328 Please check when you are convenient， thank you so much. 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-10157) JSON Facets should give more helpful error msg when users attempt to an unknown aggregation
[
https://issues.apache.org/jira/browse/SOLR-10157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-10157:
Attachment: SOLR-10157.patch
> JSON Facets should give more helpful error msg when users attempt to an
> unknown aggregation
> ---
>
> Key: SOLR-10157
> URL: https://issues.apache.org/jira/browse/SOLR-10157
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-10157.patch
>
>
> Sample question from a confused solr-user email...
> {noformat}
> > I'm getting this error when I tried to do a division in JSON Facet.
> >
> > "error":{
> > "msg":"org.apache.solr.search.SyntaxError: Unknown aggregation agg_div
> > in ('div(4,2)', pos=4)",
> > "code":400}}
> >
> >
> > Is this division function supported in JSON Facet?
> {noformat}
> And the subsequent followup from the same user...
> bq. I found that we can't put div(4,2) directly, as it wouldn't work.
> bq. It will work if I put something like max(div(4,2)).
>
> It seems like a better error handline code path for
> {{FunctionQParser.parseAgg}} (once we've confirmed no such aggregation
> exists) would be:
> * attempt to parse the original string as a regular (non-Agg)ValueSource)
> function
> ** if that succeeds, give the user an error indicating that this ValueSource
> must be wrapped in an aggregation
> ** if it fails, continue to throw the original error
> * either way, any error thrown should refer to the _original_ {{id}} before
> For example:
> * {{div(price,popularity)}} should throw an error with a msg along the lines
> of: {{'div' is a per-document function, not a multi-document aggregation
> function, input: div(price,popularity)}}
> * {{HOSS(price,popularity)}} on the other hand should throw an error such
> as: {{Unknown aggregation HOSS in ('HOSS(price,populaity)' ...}}
> ** note the message cites {{HOSS}} not {{agg_HOSS}}
--
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-10157) JSON Facets should give more helpful error msg when users attempt to an unknown aggregation
[
https://issues.apache.org/jira/browse/SOLR-10157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-10157:
Attachment: SOLR-10157.patch
> JSON Facets should give more helpful error msg when users attempt to an
> unknown aggregation
> ---
>
> Key: SOLR-10157
> URL: https://issues.apache.org/jira/browse/SOLR-10157
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-10157.patch, SOLR-10157.patch
>
>
> Sample question from a confused solr-user email...
> {noformat}
> > I'm getting this error when I tried to do a division in JSON Facet.
> >
> > "error":{
> > "msg":"org.apache.solr.search.SyntaxError: Unknown aggregation agg_div
> > in ('div(4,2)', pos=4)",
> > "code":400}}
> >
> >
> > Is this division function supported in JSON Facet?
> {noformat}
> And the subsequent followup from the same user...
> bq. I found that we can't put div(4,2) directly, as it wouldn't work.
> bq. It will work if I put something like max(div(4,2)).
>
> It seems like a better error handline code path for
> {{FunctionQParser.parseAgg}} (once we've confirmed no such aggregation
> exists) would be:
> * attempt to parse the original string as a regular (non-Agg)ValueSource)
> function
> ** if that succeeds, give the user an error indicating that this ValueSource
> must be wrapped in an aggregation
> ** if it fails, continue to throw the original error
> * either way, any error thrown should refer to the _original_ {{id}} before
> For example:
> * {{div(price,popularity)}} should throw an error with a msg along the lines
> of: {{'div' is a per-document function, not a multi-document aggregation
> function, input: div(price,popularity)}}
> * {{HOSS(price,popularity)}} on the other hand should throw an error such
> as: {{Unknown aggregation HOSS in ('HOSS(price,populaity)' ...}}
> ** note the message cites {{HOSS}} not {{agg_HOSS}}
--
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-10157) JSON Facets should give more helpful error msg when users attempt to an unknown aggregation
[
https://issues.apache.org/jira/browse/SOLR-10157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059674#comment-17059674
]
Munendra S N commented on SOLR-10157:
-
[^SOLR-10157.patch]
Improved error message based on above suggestion.
> JSON Facets should give more helpful error msg when users attempt to an
> unknown aggregation
> ---
>
> Key: SOLR-10157
> URL: https://issues.apache.org/jira/browse/SOLR-10157
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-10157.patch, SOLR-10157.patch
>
>
> Sample question from a confused solr-user email...
> {noformat}
> > I'm getting this error when I tried to do a division in JSON Facet.
> >
> > "error":{
> > "msg":"org.apache.solr.search.SyntaxError: Unknown aggregation agg_div
> > in ('div(4,2)', pos=4)",
> > "code":400}}
> >
> >
> > Is this division function supported in JSON Facet?
> {noformat}
> And the subsequent followup from the same user...
> bq. I found that we can't put div(4,2) directly, as it wouldn't work.
> bq. It will work if I put something like max(div(4,2)).
>
> It seems like a better error handline code path for
> {{FunctionQParser.parseAgg}} (once we've confirmed no such aggregation
> exists) would be:
> * attempt to parse the original string as a regular (non-Agg)ValueSource)
> function
> ** if that succeeds, give the user an error indicating that this ValueSource
> must be wrapped in an aggregation
> ** if it fails, continue to throw the original error
> * either way, any error thrown should refer to the _original_ {{id}} before
> For example:
> * {{div(price,popularity)}} should throw an error with a msg along the lines
> of: {{'div' is a per-document function, not a multi-document aggregation
> function, input: div(price,popularity)}}
> * {{HOSS(price,popularity)}} on the other hand should throw an error such
> as: {{Unknown aggregation HOSS in ('HOSS(price,populaity)' ...}}
> ** note the message cites {{HOSS}} not {{agg_HOSS}}
--
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-10157) JSON Facets should give more helpful error msg when users attempt to an unknown aggregation
[
https://issues.apache.org/jira/browse/SOLR-10157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-10157:
Status: Patch Available (was: Open)
> JSON Facets should give more helpful error msg when users attempt to an
> unknown aggregation
> ---
>
> Key: SOLR-10157
> URL: https://issues.apache.org/jira/browse/SOLR-10157
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-10157.patch, SOLR-10157.patch
>
>
> Sample question from a confused solr-user email...
> {noformat}
> > I'm getting this error when I tried to do a division in JSON Facet.
> >
> > "error":{
> > "msg":"org.apache.solr.search.SyntaxError: Unknown aggregation agg_div
> > in ('div(4,2)', pos=4)",
> > "code":400}}
> >
> >
> > Is this division function supported in JSON Facet?
> {noformat}
> And the subsequent followup from the same user...
> bq. I found that we can't put div(4,2) directly, as it wouldn't work.
> bq. It will work if I put something like max(div(4,2)).
>
> It seems like a better error handline code path for
> {{FunctionQParser.parseAgg}} (once we've confirmed no such aggregation
> exists) would be:
> * attempt to parse the original string as a regular (non-Agg)ValueSource)
> function
> ** if that succeeds, give the user an error indicating that this ValueSource
> must be wrapped in an aggregation
> ** if it fails, continue to throw the original error
> * either way, any error thrown should refer to the _original_ {{id}} before
> For example:
> * {{div(price,popularity)}} should throw an error with a msg along the lines
> of: {{'div' is a per-document function, not a multi-document aggregation
> function, input: div(price,popularity)}}
> * {{HOSS(price,popularity)}} on the other hand should throw an error such
> as: {{Unknown aggregation HOSS in ('HOSS(price,populaity)' ...}}
> ** note the message cites {{HOSS}} not {{agg_HOSS}}
--
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-10157) JSON Facets should give more helpful error msg when users attempt to an unknown aggregation
[
https://issues.apache.org/jira/browse/SOLR-10157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N reassigned SOLR-10157:
---
Assignee: Munendra S N
> JSON Facets should give more helpful error msg when users attempt to an
> unknown aggregation
> ---
>
> Key: SOLR-10157
> URL: https://issues.apache.org/jira/browse/SOLR-10157
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Reporter: Chris M. Hostetter
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-10157.patch, SOLR-10157.patch
>
>
> Sample question from a confused solr-user email...
> {noformat}
> > I'm getting this error when I tried to do a division in JSON Facet.
> >
> > "error":{
> > "msg":"org.apache.solr.search.SyntaxError: Unknown aggregation agg_div
> > in ('div(4,2)', pos=4)",
> > "code":400}}
> >
> >
> > Is this division function supported in JSON Facet?
> {noformat}
> And the subsequent followup from the same user...
> bq. I found that we can't put div(4,2) directly, as it wouldn't work.
> bq. It will work if I put something like max(div(4,2)).
>
> It seems like a better error handline code path for
> {{FunctionQParser.parseAgg}} (once we've confirmed no such aggregation
> exists) would be:
> * attempt to parse the original string as a regular (non-Agg)ValueSource)
> function
> ** if that succeeds, give the user an error indicating that this ValueSource
> must be wrapped in an aggregation
> ** if it fails, continue to throw the original error
> * either way, any error thrown should refer to the _original_ {{id}} before
> For example:
> * {{div(price,popularity)}} should throw an error with a msg along the lines
> of: {{'div' is a per-document function, not a multi-document aggregation
> function, input: div(price,popularity)}}
> * {{HOSS(price,popularity)}} on the other hand should throw an error such
> as: {{Unknown aggregation HOSS in ('HOSS(price,populaity)' ...}}
> ** note the message cites {{HOSS}} not {{agg_HOSS}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource
dsmiley commented on a change in pull request #1343: LUCENE-8103: Use two-phase
iteration in Query- and DoubleValuesSource
URL: https://github.com/apache/lucene-solr/pull/1343#discussion_r392676630
##
File path:
lucene/queries/src/java/org/apache/lucene/queries/function/valuesource/QueryValueSource.java
##
@@ -139,15 +138,14 @@ public boolean exists(int doc) {
lastDocRequested = doc;
try {
- if (noMatches) return false;
if (scorer == null) {
Review comment:
This now needs to check if disi isn't null, otherwise we might call
weight.scorer a ton!
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-14329) Add support to choose field for expand component from multiple collapse groups
Munendra S N created SOLR-14329: --- Summary: Add support to choose field for expand component from multiple collapse groups Key: SOLR-14329 URL: https://issues.apache.org/jira/browse/SOLR-14329 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Munendra S N Assignee: Munendra S N SOLR-14073, Fixed NPE issue when multiple collapse groups are specified. ExpandComponent could be used with Collapse but expand only supports single field. So, There should be way to choose collapse group for expand. Low cost collapse group should be given higher priority. -- 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-14329) Add support to choose field for expand component from multiple collapse groups
[ https://issues.apache.org/jira/browse/SOLR-14329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N updated SOLR-14329: Attachment: SOLR-14329.patch > Add support to choose field for expand component from multiple collapse groups > -- > > Key: SOLR-14329 > URL: https://issues.apache.org/jira/browse/SOLR-14329 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Munendra S N >Assignee: Munendra S N >Priority: Major > Attachments: SOLR-14329.patch > > > SOLR-14073, Fixed NPE issue when multiple collapse groups are specified. > ExpandComponent could be used with Collapse but expand only supports single > field. So, There should be way to choose collapse group for expand. Low cost > collapse group should be given higher priority. -- 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-14329) Add support to choose field for expand component from multiple collapse groups
[ https://issues.apache.org/jira/browse/SOLR-14329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N updated SOLR-14329: Status: Patch Available (was: Open) > Add support to choose field for expand component from multiple collapse groups > -- > > Key: SOLR-14329 > URL: https://issues.apache.org/jira/browse/SOLR-14329 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Munendra S N >Assignee: Munendra S N >Priority: Major > Attachments: SOLR-14329.patch > > > SOLR-14073, Fixed NPE issue when multiple collapse groups are specified. > ExpandComponent could be used with Collapse but expand only supports single > field. So, There should be way to choose collapse group for expand. Low cost > collapse group should be given higher priority. -- 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-14329) Add support to choose field for expand component from multiple collapse groups
[ https://issues.apache.org/jira/browse/SOLR-14329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059678#comment-17059678 ] Munendra S N commented on SOLR-14329: - [^SOLR-14329.patch] This adds support to choose collapse group based on cost. Lowest cost given higher priority, in case of same cost first collapse group would be used. Also, contains documentation update [~jbernste] could you please review this once? > Add support to choose field for expand component from multiple collapse groups > -- > > Key: SOLR-14329 > URL: https://issues.apache.org/jira/browse/SOLR-14329 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Munendra S N >Assignee: Munendra S N >Priority: Major > Attachments: SOLR-14329.patch > > > SOLR-14073, Fixed NPE issue when multiple collapse groups are specified. > ExpandComponent could be used with Collapse but expand only supports single > field. So, There should be way to choose collapse group for expand. Low cost > collapse group should be given higher priority. -- 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] micpalmia commented on a change in pull request #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource
micpalmia commented on a change in pull request #1343: LUCENE-8103: Use
two-phase iteration in Query- and DoubleValuesSource
URL: https://github.com/apache/lucene-solr/pull/1343#discussion_r392677444
##
File path:
lucene/queries/src/java/org/apache/lucene/queries/function/valuesource/QueryValueSource.java
##
@@ -139,15 +138,14 @@ public boolean exists(int doc) {
lastDocRequested = doc;
try {
- if (noMatches) return false;
if (scorer == null) {
Review comment:
🤦🏻♂️
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-14073) Fix segment look ahead NPE in CollapsingQParserPlugin
[ https://issues.apache.org/jira/browse/SOLR-14073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059679#comment-17059679 ] Munendra S N commented on SOLR-14073: - I have created SOLR-14329 for changes in expand component. > Fix segment look ahead NPE in CollapsingQParserPlugin > - > > Key: SOLR-14073 > URL: https://issues.apache.org/jira/browse/SOLR-14073 > Project: Solr > Issue Type: Bug >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Fix For: 8.5 > > Attachments: SOLR-14073-expand.patch, SOLR-14073.patch, > SOLR-14073.patch, SOLR-14073.patch > > > The CollapsingQParserPlugin has a bug that if every segment is not visited > during the collect it throws an NPE. This causes the CollapsingQParserPlugin > to not work when used with any feature that short circuits the segments > during the collect. This includes using the CollapsingQParserPlugin twice in > the same query and the time limiting collector. -- 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-9104) NPE in CollapsingQParser when two fq={!collapse} and zero results
[
https://issues.apache.org/jira/browse/SOLR-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N resolved SOLR-9104.
Fix Version/s: (was: 6.2)
(was: 7.0)
8.5
Resolution: Fixed
SOLR-14073 fixes this. Please reopen if not the case
> NPE in CollapsingQParser when two fq={!collapse} and zero results
> -
>
> Key: SOLR-9104
> URL: https://issues.apache.org/jira/browse/SOLR-9104
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 8.5
>
>
> This is a very weird problem that is reproducible on a small production
> server, but not on the local machine although they run the same 6.0 version.,
> and have an almost identical index. The only minor difference is that
> production is a SolrCloud with 1 shard and two replica's, just for a bit of
> redundancy.
> The following query yields zero results and throws the NPE:
> {code}
> select?q=query:seis&fq={!collapse field=query_digest}&fq={!collapse
> field=result_digest}
> {code}
> The next query does yield results and does not throw anything, it just works
> as it should work:
> {code}
> select?q=query:seiz&fq={!collapse field=query_digest}&fq={!collapse
> field=result_digest}
> {code}
> The /select handler used does not add any fancy param other than rows.
> Here's the NPE:
> {code}
> 2016-05-11 14:10:27.666 ERROR (qtp1209271652-3338) [c:suggestions s:shard1
> r:core_node1 x:suggestions_shard1_replica1] o.a.s.s.HttpSolrCall
> null:java.lang.NullPointerException
> at
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:814)
> at
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:851)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:272)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1794)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1611)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:634)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:529)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:287)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> {code}
> Edit: for the sake of clarity. It really needs double fq={!collapse bla bla
> for the NPE to appear. If i remove either of the filters from the query, i
> get a nice zero resultset back. Both fields are defined as int.
--
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-10336) NPE during queryCache warming
[
https://issues.apache.org/jira/browse/SOLR-10336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N resolved SOLR-10336.
-
Fix Version/s: (was: 7.0)
8.5
Resolution: Fixed
SOLR-14073 fixes this. Please reopen if not the case
> NPE during queryCache warming
> -
>
> Key: SOLR-10336
> URL: https://issues.apache.org/jira/browse/SOLR-10336
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.4.2
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 8.5
>
>
> Regular cache warming stumbles on this NPE. It seems to be related to
> SOLR-9104, it is the same collection and the query that fails the cache
> warmer is similar to that of SOLR-9104, i.e, two CollapsingQParsers.
> {code}
> Error during auto-warming of
> key:org.apache.solr.search.QueryResultKey@fe9769ca:java.lang.NullPointerException
> at
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:816)
> at
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:853)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:256)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1823)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1640)
> at
> org.apache.solr.search.SolrIndexSearcher.lambda$initRegenerators$3(SolrIndexSearcher.java:604)
> at org.apache.solr.search.LFUCache.warm(LFUCache.java:188)
> at
> org.apache.solr.search.SolrIndexSearcher.warm(SolrIndexSearcher.java:2376)
> at
> org.apache.solr.core.SolrCore.lambda$getSearcher$2(SolrCore.java:2054)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7435) NPE can occur if CollapsingQParserPlugin is used two or more times in the same query
[
https://issues.apache.org/jira/browse/SOLR-7435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N resolved SOLR-7435.
Fix Version/s: (was: 5.5)
8.5
Resolution: Fixed
SOLR-14073 fixes this. Please reopen if not the case
> NPE can occur if CollapsingQParserPlugin is used two or more times in the
> same query
>
>
> Key: SOLR-7435
> URL: https://issues.apache.org/jira/browse/SOLR-7435
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.8.1, 4.9.1, 4.10.1, 4.10.3, 4.10.4, 5.1, 5.2, 5.2.1,
> 5.3
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: 8.5
>
>
> The problem is that Solr 4.10.3,
> CollapsingFieldValueCollector.finish(CollapsingQParserPlugin.java:632) is
> looking ahead to the next segment. When you use the CollapsingQParser only
> once that look-ahead is always populated because each segment is processed by
> the scorers. The CollapsingQParser plugin does not process every segment
> though, it stops when it runs out of documents that have been collected. So
> the look-ahead can cause a null pointer in the second Collapse. This is a
> problem in every version of the CollapsingQParserPlugin.
> Below is the original description from Markus which is another NPE during a
> look-ahead in Solr 5.1:
> Not even sure it would work anyway, i tried to collapse on two distinct
> fields, ending up with this:
> select?q=*:*&fq={!collapse field=qst}&fq={!collapse field=rdst}
> {code}
> 584550 [qtp1121454968-20] ERROR org.apache.solr.servlet.SolrDispatchFilter [
> suggests] – null:java.lang.NullPointerException
> at
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:743)
> at
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:780)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:203)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1660)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1479)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:556)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:518)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:368)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
> at
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
> at org.eclipse.jetty.http.HttpParser.parseN
[jira] [Resolved] (SOLR-8834) NPE for BlockJoinFacetComponent and facet.prefix not working
[
https://issues.apache.org/jira/browse/SOLR-8834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N resolved SOLR-8834.
Resolution: Won't Fix
As SOLR-14051 removes this component marking this as won't fix
> NPE for BlockJoinFacetComponent and facet.prefix not working
>
>
> Key: SOLR-8834
> URL: https://issues.apache.org/jira/browse/SOLR-8834
> Project: Solr
> Issue Type: Bug
> Components: faceting
>Affects Versions: 5.5
>Reporter: Vijay Sekhri
>Priority: Minor
> Attachments: SOLR-8834.patch
>
>
> Sometime for some types of queries a NPE is thrown . This is the code where
> it was happening.
> {code}
> 14:00:20,751 ERROR [org.apache.solr.servlet.HttpSolrCall]
> (http-/10.235.43.43:8580-82) null:java.lang.NullPointerException
> at
> org.apache.solr.search.join.BlockJoinFacetCollector.incrementFacets(BlockJoinFacetCollector.java:100)
> at
> org.apache.solr.search.join.BlockJoinFacetCollector.collect(BlockJoinFacetCollector.java:87)
> {code}
> It could be related to stats query that does not even have any
> ToParentBlockJoin syntax . Here is one example
> {code}
> 15:07:56,736 INFO [org.apache.solr.core.SolrCore.Request]
> (http-/10.235.43.43:8580-143) [core1] webapp=/solr path=/select
> params={shards.qt=searchStandard&tie=0.01&stats=true&distrib=false&q.alt=*:*&originIP=10.235.52.131&collection=search1&shards.tolerant=true&version=2&NOW=1454360876733&shard.url=http://solrx331p.qa.ch3.s.com:8580/solr/core1/|http://solrx351p.qa.ch3.s.com:8580/solr/core1/&fl=id&fl=score&bf=%0a&timeAllowed=1&qt=searchStandard&fsv=true&fq=catalogs:(("10104"))&fq=searchableAttributes:(("Metal%3DTri+color"))&fq=brand:("Black+Hills+Gold")&fq=discount:("70")&fq=primaryCategory:("10104_3_Jewelry_Diamonds_Rings")&mm=%0a2<-1+5<-2+6<-50%25%0a&hasOrigCategories=1&qf=%0a+primaryLnames^5.0+partnumber^11.0+itemnumber^11.0+fullmfpartno^5.0+mfpartno^5.0+xref^10.0+storeOriginSearchable^3.0+nameSearchable^10.0+brandSearchable^5.0++searchPhrase^1.0++searchableAttributesSearchable^1.0%0a&wt=javabin&rows=0&pf=%0a+++primaryLnames^0.5+nameSearchable^1.0+storeOriginSearchable^0.3+brandSearchable^0.5++xref^1.1+searchableAttributesSearchable^0.1%0a&shards.purpose=516&start=0&q=white+diamonds+diamonds+elizabeth+taylor+body+lotion&bot=true&stats.field=price_10151_f&isShard=true&ps=100}
> hits=0 status=0 QTime=0
> 15:07:56,758 ERROR [org.apache.solr.handler.RequestHandlerBase]
> (http-/10.235.43.43:8580-26) java.lang.NullPointerException
> at
> org.apache.solr.search.join.BlockJoinFacetCollector.incrementFacets(BlockJoinFacetCollector.java:100)
> at
> org.apache.solr.search.join.BlockJoinFacetCollector.collect(BlockJoinFacetCollector.java:87)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:1153)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:350)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
> {code}
> Furthermore,
> when facet.prefix is passed it is not being honored by child.facet.
--
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-14031) Make BlockJoinFacetComponentSupport protected instead of package private
[ https://issues.apache.org/jira/browse/SOLR-14031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N resolved SOLR-14031. - Resolution: Won't Fix As SOLR-14051 removes this component, marking this as won't fix > Make BlockJoinFacetComponentSupport protected instead of package private > > > Key: SOLR-14031 > URL: https://issues.apache.org/jira/browse/SOLR-14031 > Project: Solr > Issue Type: Improvement >Reporter: Kelvin Tan >Priority: Minor > Attachments: SOLR-14031.patch > > > BlockJoinFacetComponentSupport is currently package private which makes it > impossible for users to create searchcomponents derived from it and to also > deploy these custom components in the lib/ directory of the solr core due to > the Java's classloading mechanism. > Relax it to protected so that this is possible. -- 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-9278) Make javadoc folder structure follow Gradle project path
[
https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059693#comment-17059693
]
Tomoko Uchida commented on LUCENE-9278:
---
I noticed there are "hard-coded" relative paths to another modules in
{{o.a.l.a.Analyzer}} javadoc.
[https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/analysis/Analyzer.java#L66]
{code:java}
* Common:
* Analyzers for indexing content in different languages and domains.
* ICU:
* Exposes functionality from ICU to Apache Lucene.
* Kuromoji:
* Morphological analyzer for Japanese text.
* Morfologik:
* Dictionary-driven lemmatization for the Polish language.
* Phonetic:
* Analysis for indexing phonetic signatures (for sounds-alike search).
* Smart
Chinese:
* Analyzer for Simplified Chinese, which indexes words.
* Stempel:
{code}
As you see the links include ant project names. We need to keep them as long as
we use ant build as our primary build system, and change them to the gradle
project paths (analysis/common, etc.) soon after we switch to gradle build,
otherwise the links will be broken. I cannot figure out a feasible option to
make ant and gradle build co-exist here.
So far, we set two goals for gradle javadoc task.
([https://github.com/apache/lucene-solr/pull/1304])
- Not to use centralized output folder. Instead, docs should go to isolated,
per project build folder.
- Make the javadoc folder hierarchy obey gradle project paths, not ant ones.
While it would be certainly possible to achieve them without harming the
complexed inter-project links (the only problem what's puzzling me here is the
"hyperlinks" between modules), we may need a careful migration strategy (and
also a gradle version "broken links check" script) for that. I just got stuck
in the small pond... give me some time to find a better solution.
> Make javadoc folder structure follow Gradle project path
>
>
> Key: LUCENE-9278
> URL: https://issues.apache.org/jira/browse/LUCENE-9278
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Current javadoc folder structure is derived from Ant project name. e.g.:
> [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html]
> [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html]
> For Gradle build, it should also follow gradle project structure (path)
> instead of ant one, to keep things simple to manage [1]. Hence, it will look
> like this:
> [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html]
> [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html]
> [1] The change was suggested at the conversation between Dawid Weiss and I on
> a github pr: [https://github.com/apache/lucene-solr/pull/1304]
--
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-13765) Deadlock on Solr cloud request causing 'Too many open files' error
[
https://issues.apache.org/jira/browse/SOLR-13765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N resolved SOLR-13765.
-
Resolution: Duplicate
Even though the description is different, cause is same as SOLR-13793. Closing
this
> Deadlock on Solr cloud request causing 'Too many open files' error
> --
>
> Key: SOLR-13765
> URL: https://issues.apache.org/jira/browse/SOLR-13765
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.7.2
>Reporter: Lei Wu
>Priority: Major
>
> Hi there,
> We are seeing an issue about deadlock on Solr cloud request.
> Say we have a collection with one shard and two replicas for that shard. For
> whatever reason the cluster appears to be active but each individual replica
> is down. And when a request comes in, Solr (replica 1) tries to find a remote
> node (replica 2) to handle the request since the local core (replica 1) is
> down and when the other node (replica 2) receives the request it does the
> same to forward the request back to the original node (replica 1). This
> causes deadlock and eventually uses all the socket causing
> `{color:#FF}Too many open files{color}`.
> Not sure what the purpose of finding an inactive node to handle request in
> HttpSolrCall.getRemoteCoreUrl but taking that out seems to fix the problem
--
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-14330) Return docs with null value for field when collapse has nullPolicy=collapse
Munendra S N created SOLR-14330:
---
Summary: Return docs with null value for field when collapse has
nullPolicy=collapse
Key: SOLR-14330
URL: https://issues.apache.org/jira/browse/SOLR-14330
Project: Solr
Issue Type: Wish
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Munendra S N
When documents doesn't contain value for field then, with collapse either those
documents could be either ignored(default), collapsed(one document is chosen)
or expanded(all are returned). This is controlled by {{nullPolicy}}
When {{nullPolicy}} is {{collapse}}, it would be nice to return all documents
with {{null}} value in expand block if {{expand=true}}
Also, when used with {{expand.field}}, even then we should return such documents
--
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-14330) Return docs with null value in expand for field when collapse has nullPolicy=collapse
[
https://issues.apache.org/jira/browse/SOLR-14330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-14330:
Summary: Return docs with null value in expand for field when collapse has
nullPolicy=collapse (was: Return docs with null value for field when collapse
has nullPolicy=collapse)
> Return docs with null value in expand for field when collapse has
> nullPolicy=collapse
> -
>
> Key: SOLR-14330
> URL: https://issues.apache.org/jira/browse/SOLR-14330
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Priority: Major
>
> When documents doesn't contain value for field then, with collapse either
> those documents could be either ignored(default), collapsed(one document is
> chosen) or expanded(all are returned). This is controlled by {{nullPolicy}}
> When {{nullPolicy}} is {{collapse}}, it would be nice to return all documents
> with {{null}} value in expand block if {{expand=true}}
> Also, when used with {{expand.field}}, even then we should return such
> documents
--
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-14331) Support expand component on multiple fields in single field
Munendra S N created SOLR-14331: --- Summary: Support expand component on multiple fields in single field Key: SOLR-14331 URL: https://issues.apache.org/jira/browse/SOLR-14331 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: Munendra S N SOLR-14073 adds support for multiple collapse and SOLR-14329 adds support to choose collapse group for expand with multiple collapse. Evaluate if it is possible to support expand on multiple collapse groups/fields. Each field will contain different block in the response -- 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-14332) Return field in expand component response
Munendra S N created SOLR-14332: --- Summary: Return field in expand component response Key: SOLR-14332 URL: https://issues.apache.org/jira/browse/SOLR-14332 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Munendra S N Current expand component response doesn't contain field on which expand was executed. When SOLR-14329 and SOLR-14330 land in master, then there has to be way for user to know the expanded field -- 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-14333) Implement toString() in CollapsingPostFilter
Munendra S N created SOLR-14333:
---
Summary: Implement toString() in CollapsingPostFilter
Key: SOLR-14333
URL: https://issues.apache.org/jira/browse/SOLR-14333
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Munendra S N
{{toString()}} is not overridden in CollapsingPostFilter. Debug component
returns {{parsed_filter_queries}}, for multiple CollapsingPostFilter in
request, value in {{parsed_filter_queries}} is always {{CollapsingPostFilter()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley closed pull request #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource
dsmiley closed pull request #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource URL: https://github.com/apache/lucene-solr/pull/1343 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] (LUCENE-8103) QueryValueSource should use TwoPhaseIterator
[ https://issues.apache.org/jira/browse/LUCENE-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved LUCENE-8103. -- Fix Version/s: 8.6 Assignee: David Smiley Resolution: Fixed _(strangely no auto-posts for the commits but they did happen on master and branch_8x)_ Thanks for contributing! > QueryValueSource should use TwoPhaseIterator > > > Key: LUCENE-8103 > URL: https://issues.apache.org/jira/browse/LUCENE-8103 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/other >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 8.6 > > Attachments: LUCENE-8103.patch, LUCENE-8103.patch > > Time Spent: 3.5h > Remaining Estimate: 0h > > QueryValueSource (in "queries" module) is a ValueSource representation of a > Query; the score is the value. It ought to try to use a TwoPhaseIterator > from the query if it can be offered. This will prevent possibly expensive > advancing beyond documents that we aren't interested in. -- 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-14334) Semi-reproducing seed for testSmileRequest
Erick Erickson created SOLR-14334: - Summary: Semi-reproducing seed for testSmileRequest Key: SOLR-14334 URL: https://issues.apache.org/jira/browse/SOLR-14334 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Erick Erickson ant test -Dtestcase=TestSmileRequest -Dtests.method=testDistribJsonRequest -Dtests.seed=D8AF63C0745DA4AF -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=en -Dtests.timezone=Australia/South -Dtests.asserts=true -Dtests.file.encoding=UTF-8 It failed 3 of 4 runs. 2 of the failures were when I was testing the upgrade for ZK and Netty, the other failure was on a fresh, unmodified pull of Solr. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[
https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059726#comment-17059726
]
Tomoko Uchida commented on LUCENE-9278:
---
sorry for a bit random comment... i need a place to write down my brief
thoughts on migration.
First of all, we should simply close the PR here, to throw away all relative
paths "{{../_project_}}" and replace them with absolute urls
"{{[https://lucene.apache.org/core/_version_/_project_]}}"; so that the projects
are isolated from each other. LUCENE-9242 is still opened for the work. Then,
we need to create a broken links check script that emulates the
"checkJavadocLinks.py" but works with absolute urls instead of relative paths
(anyway we cannot reuse "checkJavadocLinks.py" for gradle build). We have
already LUCENE-9201 for this.
> Make javadoc folder structure follow Gradle project path
>
>
> Key: LUCENE-9278
> URL: https://issues.apache.org/jira/browse/LUCENE-9278
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Current javadoc folder structure is derived from Ant project name. e.g.:
> [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html]
> [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html]
> For Gradle build, it should also follow gradle project structure (path)
> instead of ant one, to keep things simple to manage [1]. Hence, it will look
> like this:
> [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html]
> [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html]
> [1] The change was suggested at the conversation between Dawid Weiss and I on
> a github pr: [https://github.com/apache/lucene-solr/pull/1304]
--
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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059729#comment-17059729 ] Uwe Schindler commented on LUCENE-9278: --- I disagree to replace them by absolute URLs, as this makes testing and snapshot builds impossible. Keep the relative links for now, but fix them to be correct after full switch to Gradle. > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059734#comment-17059734 ] Tomoko Uchida commented on LUCENE-9278: --- I'm not going to touch existing ant build files or Javadocs (until we eventually drop the ant build), but uses absolute urls only on gradle build scripts for preparing to switch to gradle. Still, is my plan affects on existing tests or builds...? > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059734#comment-17059734 ] Tomoko Uchida edited comment on LUCENE-9278 at 3/15/20, 5:03 PM: - I'm not going to touch existing ant build files or Javadocs (until we eventually drop the ant build), but uses absolute urls only on gradle build scripts for preparing to switch to gradle. Still, does my plan affect on existing tests or builds...? was (Author: tomoko uchida): I'm not going to touch existing ant build files or Javadocs (until we eventually drop the ant build), but uses absolute urls only on gradle build scripts for preparing to switch to gradle. Still, is my plan affects on existing tests or builds...? > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-8103) QueryValueSource should use TwoPhaseIterator
[
https://issues.apache.org/jira/browse/LUCENE-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059738#comment-17059738
]
Munendra S N commented on LUCENE-8103:
--
This also contains change were {{objectValue(doc)}} calls {{floatValue(doc)}}
which returns default value if {{exists(doc)}} returns {{false}} but previously
{{objectValue(doc)}} used to return {{null}} exists returned false even if
default value is specified (in pure lucene case, there will always be default
value). If this is expected change/fix should we document the change is
behavior?
This also resolves LUCENE-8908. Also, I wanted to share this
[comment|https://issues.apache.org/jira/browse/LUCENE-8908?focusedCommentId=16887518&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16887518]
which is from Solr's perspective as {{query}} could be used even without
default value.
Just sharing my thoughts, please free to ignore if it doesn't apply here
> QueryValueSource should use TwoPhaseIterator
>
>
> Key: LUCENE-8103
> URL: https://issues.apache.org/jira/browse/LUCENE-8103
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/other
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.6
>
> Attachments: LUCENE-8103.patch, LUCENE-8103.patch
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> QueryValueSource (in "queries" module) is a ValueSource representation of a
> Query; the score is the value. It ought to try to use a TwoPhaseIterator
> from the query if it can be offered. This will prevent possibly expensive
> advancing beyond documents that we aren't interested in.
--
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] (LUCENE-8103) QueryValueSource should use TwoPhaseIterator
[
https://issues.apache.org/jira/browse/LUCENE-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059738#comment-17059738
]
Munendra S N edited comment on LUCENE-8103 at 3/15/20, 5:19 PM:
This also contains change were {{objectValue(doc)}} calls {{floatValue(doc)}}
which returns default value if {{exists(doc)}} returns {{false}} but previously
{{objectValue(doc)}} used to return {{null}} exists returned false even if
default value is specified (in pure lucene case, there will always be default
value). If this is expected change/fix should we document the change in
behavior?
Above change resolves LUCENE-8908. Also, I wanted to share this
[comment|https://issues.apache.org/jira/browse/LUCENE-8908?focusedCommentId=16887518&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16887518]
which is from Solr's perspective as {{query}} could be used even without
default value.
Just sharing my thoughts, please free to ignore if it doesn't apply here
was (Author: munendrasn):
This also contains change were {{objectValue(doc)}} calls {{floatValue(doc)}}
which returns default value if {{exists(doc)}} returns {{false}} but previously
{{objectValue(doc)}} used to return {{null}} exists returned false even if
default value is specified (in pure lucene case, there will always be default
value). If this is expected change/fix should we document the change is
behavior?
This also resolves LUCENE-8908. Also, I wanted to share this
[comment|https://issues.apache.org/jira/browse/LUCENE-8908?focusedCommentId=16887518&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16887518]
which is from Solr's perspective as {{query}} could be used even without
default value.
Just sharing my thoughts, please free to ignore if it doesn't apply here
> QueryValueSource should use TwoPhaseIterator
>
>
> Key: LUCENE-8103
> URL: https://issues.apache.org/jira/browse/LUCENE-8103
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/other
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.6
>
> Attachments: LUCENE-8103.patch, LUCENE-8103.patch
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> QueryValueSource (in "queries" module) is a ValueSource representation of a
> Query; the score is the value. It ought to try to use a TwoPhaseIterator
> from the query if it can be offered. This will prevent possibly expensive
> advancing beyond documents that we aren't interested in.
--
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-8103) QueryValueSource should use TwoPhaseIterator
[
https://issues.apache.org/jira/browse/LUCENE-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059753#comment-17059753
]
Michele Palmia commented on LUCENE-8103:
I purposefully made that change to {{objectValue(doc)}} because the former
implementation seemed problematic, since it arbitrarily returned {{null}}
instead of the default value. I guess I should have been more clear about that
with [~dsmiley], not sure whether he agreed with my fix or he overlooked it. So
definitely thanks for bringing this up!
I don't fully understand the comment you linked though, so I'll try to study
that issue later. I hope David will have a more constructive answer :)
> QueryValueSource should use TwoPhaseIterator
>
>
> Key: LUCENE-8103
> URL: https://issues.apache.org/jira/browse/LUCENE-8103
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/other
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.6
>
> Attachments: LUCENE-8103.patch, LUCENE-8103.patch
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> QueryValueSource (in "queries" module) is a ValueSource representation of a
> Query; the score is the value. It ought to try to use a TwoPhaseIterator
> from the query if it can be offered. This will prevent possibly expensive
> advancing beyond documents that we aren't interested in.
--
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] arysin opened a new pull request #1354: LUCENE-9279: Update dictionary version for Ukrainian analyzer
arysin opened a new pull request #1354: LUCENE-9279: Update dictionary version for Ukrainian analyzer URL: https://github.com/apache/lucene-solr/pull/1354 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] dweiss commented on issue #1354: LUCENE-9279: Update dictionary version for Ukrainian analyzer
dweiss commented on issue #1354: LUCENE-9279: Update dictionary version for Ukrainian analyzer URL: https://github.com/apache/lucene-solr/pull/1354#issuecomment-599265729 Looks good to me, thanks Andriy! 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] dweiss merged pull request #1354: LUCENE-9279: Update dictionary version for Ukrainian analyzer
dweiss merged pull request #1354: LUCENE-9279: Update dictionary version for Ukrainian analyzer URL: https://github.com/apache/lucene-solr/pull/1354 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] (LUCENE-9279) Update dictionary version for Ukrainian analyzer to 4.9.0
[ https://issues.apache.org/jira/browse/LUCENE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-9279. - Fix Version/s: master (9.0) Assignee: Dawid Weiss Resolution: Fixed > Update dictionary version for Ukrainian analyzer to 4.9.0 > - > > Key: LUCENE-9279 > URL: https://issues.apache.org/jira/browse/LUCENE-9279 > Project: Lucene - Core > Issue Type: Bug >Reporter: Andriy Rysin >Assignee: Dawid Weiss >Priority: Minor > Fix For: master (9.0) > > Time Spent: 1h > Remaining Estimate: 0h > > Update morfologik dictionary version to 4.9.0 for Ukrainian analyzer. > There's about 80k of new lemmas -- 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-9279) Update dictionary version for Ukrainian analyzer to 4.9.0
[ https://issues.apache.org/jira/browse/LUCENE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059819#comment-17059819 ] Dawid Weiss commented on LUCENE-9279: - Oh - one more thing: CHANGES.txt would probably need to include this change too. > Update dictionary version for Ukrainian analyzer to 4.9.0 > - > > Key: LUCENE-9279 > URL: https://issues.apache.org/jira/browse/LUCENE-9279 > Project: Lucene - Core > Issue Type: Bug >Reporter: Andriy Rysin >Assignee: Dawid Weiss >Priority: Minor > Fix For: master (9.0) > > Time Spent: 1h > Remaining Estimate: 0h > > Update morfologik dictionary version to 4.9.0 for Ukrainian analyzer. > There's about 80k of new lemmas -- 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-9279) Update dictionary version for Ukrainian analyzer to 4.9.0
[ https://issues.apache.org/jira/browse/LUCENE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059816#comment-17059816 ] Dawid Weiss commented on LUCENE-9279: - Would you provide a pull request for 8x as well, Andriy? > Update dictionary version for Ukrainian analyzer to 4.9.0 > - > > Key: LUCENE-9279 > URL: https://issues.apache.org/jira/browse/LUCENE-9279 > Project: Lucene - Core > Issue Type: Bug >Reporter: Andriy Rysin >Assignee: Dawid Weiss >Priority: Minor > Fix For: master (9.0) > > Time Spent: 1h > Remaining Estimate: 0h > > Update morfologik dictionary version to 4.9.0 for Ukrainian analyzer. > There's about 80k of new lemmas -- 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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059821#comment-17059821 ] Dawid Weiss commented on LUCENE-9278: - I think the larger problem here is that parent module references submodules which creates a circular reference (because ordinarily these would be javadoc links not relative URLs). It's a chicken-and-egg problem. I understand it's valuable to have an overview of implementations but those relative URLs are crap in any context other than publishing to the website (as a whole): what do they point to when you publish artifacts on maven central? Or when they're downloaded by IDEs for context suggestions? > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-14329) Add support to choose field for expand component from multiple collapse groups
[
https://issues.apache.org/jira/browse/SOLR-14329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059836#comment-17059836
]
Lucene/Solr QA commented on SOLR-14329:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
7s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate ref guide {color} |
{color:green} 1m 9s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 48m
30s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 53m 23s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-14329 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12996772/SOLR-14329.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns validaterefguide |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 73b618a55c2 |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/714/testReport/ |
| modules | C: solr/core solr/solr-ref-guide U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/714/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Add support to choose field for expand component from multiple collapse groups
> --
>
> Key: SOLR-14329
> URL: https://issues.apache.org/jira/browse/SOLR-14329
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-14329.patch
>
>
> SOLR-14073, Fixed NPE issue when multiple collapse groups are specified.
> ExpandComponent could be used with Collapse but expand only supports single
> field. So, There should be way to choose collapse group for expand. Low cost
> collapse group should be given higher priority.
--
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-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059837#comment-17059837 ] Tomoko Uchida commented on LUCENE-9278: --- I have ported this tweak on each element-list from Ant javadoc macro to the custom gradle "renderJavadoc" task (this is already merged into master): https://github.com/apache/lucene-solr/blob/master/gradle/render-javadoc.gradle#L117 I thought that fix resolves circular dependency problem, but do we need additional treatment here...? > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059837#comment-17059837 ] Tomoko Uchida edited comment on LUCENE-9278 at 3/15/20, 11:32 PM: -- I have ported this tweak on each element-list from Ant javadoc macro to the custom gradle "renderJavadoc" task (this is already merged into master): https://github.com/apache/lucene-solr/blob/master/gradle/render-javadoc.gradle#L117 I thought that fixes circular dependency problem, but do we need additional treatment here...? was (Author: tomoko uchida): I have ported this tweak on each element-list from Ant javadoc macro to the custom gradle "renderJavadoc" task (this is already merged into master): https://github.com/apache/lucene-solr/blob/master/gradle/render-javadoc.gradle#L117 I thought that fix resolves circular dependency problem, but do we need additional treatment here...? > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- 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-9278) Make javadoc folder structure follow Gradle project path
[
https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059838#comment-17059838
]
Tomoko Uchida commented on LUCENE-9278:
---
{quote}I think the larger problem here is that parent module references
submodules which creates a circular reference
{quote}
Maybe I missed the point(?). Yes a "core" module class ({{o.a.l.a.Analyzer}})
refers another module by hard-coded relative paths in the Javadoc (not sure
there are other links similar to this). I do not think we can convert them into
absolute urls, let them as they are (but rewrite the paths when switching to
gradle)...
> Make javadoc folder structure follow Gradle project path
>
>
> Key: LUCENE-9278
> URL: https://issues.apache.org/jira/browse/LUCENE-9278
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Current javadoc folder structure is derived from Ant project name. e.g.:
> [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html]
> [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html]
> For Gradle build, it should also follow gradle project structure (path)
> instead of ant one, to keep things simple to manage [1]. Hence, it will look
> like this:
> [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html]
> [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html]
> [1] The change was suggested at the conversation between Dawid Weiss and I on
> a github pr: [https://github.com/apache/lucene-solr/pull/1304]
--
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-14312) Upgrade Zookeeper to 3.5.7
[ https://issues.apache.org/jira/browse/SOLR-14312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-14312: -- Attachment: SOLR-14312_8x.patch SOLR-14312_master.patch Status: Open (was: Open) Attaching patches for 8x and master since I also updated the Gradle dependencies. > Upgrade Zookeeper to 3.5.7 > -- > > Key: SOLR-14312 > URL: https://issues.apache.org/jira/browse/SOLR-14312 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-14312_8x.patch, SOLR-14312_master.patch > > > I started looking at upgrading ZK to 3.5.7, and meanwhile 3.6.0 was just > released. The 3.5.7 upgrade is pretty painless, just upgrade the version and > all tests pass. There have been some third-party CVEs and the like fixed, so > it seems worthwhile. > But I've been working on this _very_ gradually while traveling, and meanwhile > 3.6.0 just came out. Should we: > 1> upgrade to 3.5.7 now and then worry about 3.6.0 after it has some more > mileage > 2> upgrade to 3.6.0 now > 3> do nothing until 3.6.0 has some more mileage on it? > <1> gets my vote -- 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-14312) Upgrade Zookeeper to 3.5.7
[ https://issues.apache.org/jira/browse/SOLR-14312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14312. --- Fix Version/s: 8.6 Resolution: Fixed > Upgrade Zookeeper to 3.5.7 > -- > > Key: SOLR-14312 > URL: https://issues.apache.org/jira/browse/SOLR-14312 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: 8.6 > > Attachments: SOLR-14312_8x.patch, SOLR-14312_master.patch > > > I started looking at upgrading ZK to 3.5.7, and meanwhile 3.6.0 was just > released. The 3.5.7 upgrade is pretty painless, just upgrade the version and > all tests pass. There have been some third-party CVEs and the like fixed, so > it seems worthwhile. > But I've been working on this _very_ gradually while traveling, and meanwhile > 3.6.0 just came out. Should we: > 1> upgrade to 3.5.7 now and then worry about 3.6.0 after it has some more > mileage > 2> upgrade to 3.6.0 now > 3> do nothing until 3.6.0 has some more mileage on it? > <1> gets my vote -- 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-14312) Upgrade Zookeeper to 3.5.7
[ https://issues.apache.org/jira/browse/SOLR-14312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059896#comment-17059896 ] Erick Erickson commented on SOLR-14312: --- Don't see the git coming through, may have messed up my commit message. Master: 6c1d992fad4c93c6821c97c54e6fa866413205c3 8x: 2755ef992bf3c8e769aedf4dc3ac5dd312740233 > Upgrade Zookeeper to 3.5.7 > -- > > Key: SOLR-14312 > URL: https://issues.apache.org/jira/browse/SOLR-14312 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: 8.6 > > Attachments: SOLR-14312_8x.patch, SOLR-14312_master.patch > > > I started looking at upgrading ZK to 3.5.7, and meanwhile 3.6.0 was just > released. The 3.5.7 upgrade is pretty painless, just upgrade the version and > all tests pass. There have been some third-party CVEs and the like fixed, so > it seems worthwhile. > But I've been working on this _very_ gradually while traveling, and meanwhile > 3.6.0 just came out. Should we: > 1> upgrade to 3.5.7 now and then worry about 3.6.0 after it has some more > mileage > 2> upgrade to 3.6.0 now > 3> do nothing until 3.6.0 has some more mileage on it? > <1> gets my vote -- 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-14296) Update netty to 4.1.47
[ https://issues.apache.org/jira/browse/SOLR-14296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-14296: -- Fix Version/s: 8.6 Resolution: Fixed Status: Resolved (was: Patch Available) Fixed as part of SOLR-14312. Thanks [~asalamon74] ! > Update netty to 4.1.47 > -- > > Key: SOLR-14296 > URL: https://issues.apache.org/jira/browse/SOLR-14296 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Andras Salamon >Priority: Minor > Fix For: 8.6 > > Attachments: SOLR-14296-01.patch > > > There are two CVEs against the current netty version: > [https://nvd.nist.gov/vuln/detail/CVE-2019-20444] > [https://nvd.nist.gov/vuln/detail/CVE-2019-20445] > Although solr is not affected it would be still good to update netty. > The first non-affected netty version is 4.1.45 but during the update I've > found a netty bug ( [https://github.com/netty/netty/issues/10017] ) so it's > better to update to 4.1.46 -- 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-8103) QueryValueSource should use TwoPhaseIterator
[ https://issues.apache.org/jira/browse/LUCENE-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059939#comment-17059939 ] David Smiley commented on LUCENE-8103: -- Thanks for looking Munendra! Whoops; I should have looked more carefully at that. I will revert that piece immediately. I think this issue should simply be an optimization and not a semantic/behavior change as well. Not that I disagree with the change but it shouldn't be lumped together. > QueryValueSource should use TwoPhaseIterator > > > Key: LUCENE-8103 > URL: https://issues.apache.org/jira/browse/LUCENE-8103 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/other >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 8.6 > > Attachments: LUCENE-8103.patch, LUCENE-8103.patch > > Time Spent: 3.5h > Remaining Estimate: 0h > > QueryValueSource (in "queries" module) is a ValueSource representation of a > Query; the score is the value. It ought to try to use a TwoPhaseIterator > from the query if it can be offered. This will prevent possibly expensive > advancing beyond documents that we aren't interested in. -- 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-9278) Make javadoc folder structure follow Gradle project path
[
https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059975#comment-17059975
]
Tomoko Uchida commented on LUCENE-9278:
---
Just to clarify the situation here... we have two types of relative paths
(inter-module links).
1) "hard-coded" relative paths which exist in Javadoc description.
e.g.:
[https://lucene.apache.org/core/8_4_1/core/org/apache/lucene/analysis/Analyzer.html]
At least {{Analyzer}} class has this type of links. Not sure there are other
same kind of links.
We cannot modify them until we stop using Ant for generating javadocs. Also, I
don't see any way to convert them to absolute urls (for now), so just rewrite
the paths after switching Gradle to avoid broken links. (We may have to remove
those hand crafted links from javadocs and figure out better ways to refer
another module from "core", but it should be considered on another issue.)
2) Auto generated relative paths by {{}} element of Ant
javadoc task.
e.g.:
[https://lucene.apache.org/core/8_4_1/analyzers-icu/org/apache/lucene/analysis/icu/ICUFoldingFilterFactory.html]
I believe we can change all of them to absolute urls from the gradle build,
just as Solr docs refers to Lucene docs
([https://lucene.apache.org/solr/8_4_1/solr-core/org/apache/solr/analysis/ReversedWildcardFilter.html])
but have not yet tried. We can start to work for that from now on because it's
all about gradle build and does not have any effect to ant (I think).
Please let me know if I'm missing something.
> Make javadoc folder structure follow Gradle project path
>
>
> Key: LUCENE-9278
> URL: https://issues.apache.org/jira/browse/LUCENE-9278
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Current javadoc folder structure is derived from Ant project name. e.g.:
> [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html]
> [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html]
> For Gradle build, it should also follow gradle project structure (path)
> instead of ant one, to keep things simple to manage [1]. Hence, it will look
> like this:
> [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html]
> [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html]
> [1] The change was suggested at the conversation between Dawid Weiss and I on
> a github pr: [https://github.com/apache/lucene-solr/pull/1304]
--
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
