[jira] [Commented] (LUCENE-8146) Unit tests using StringHelper fail with ExceptionInInitializerError for maven surefire >= 2.18
[
https://issues.apache.org/jira/browse/LUCENE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16348517#comment-16348517
]
Julien Massenet commented on LUCENE-8146:
-
There is, in the form of the ticket that introduced the (intentional) change in
the first place (linked in the ticket already):
https://issues.apache.org/jira/browse/SUREFIRE-649.
> Unit tests using StringHelper fail with ExceptionInInitializerError for maven
> surefire >= 2.18
> --
>
> Key: LUCENE-8146
> URL: https://issues.apache.org/jira/browse/LUCENE-8146
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.2.1
>Reporter: Julien Massenet
>Priority: Minor
> Attachments: LUCENE-8146-seed_issue.tar.gz, LUCENE-8146_v1.patch,
> LUCENE-8146_v2.patch
>
>
> This happens when multiple conditions are met:
> * The client code is built with Maven
> * To execute its unit tests, the client code relies on the
> {{maven-surefire-plugin}}, with a version greater than 2.17 (last working
> version)
> * The client code uses the {{org.apache.lucene.util.StringHelper}} class
> (even transitively)
> * The client is configured as with the standard Lucene maven build (i.e. it
> is possible to fix the test seed using the {{tests.seed}} property)
> There was a change in Surefire's behavior starting with 2.18: when a property
> is empty, instead of not sending it to the test runner, it will be sent with
> an empty value.
> This behavior can be observed with the attached sample project:
> * {{mvn test}}: fails with a {{java.lang.ExceptionInInitializerError}}
> * {{mvn test -Dtests.seed=123456}}: succeeds because the property is set to
> a real value
> * {{mvn test -Dsurefire.version=2.17}}: succeeds because the surefire
> version is lower than 2.18
> Attached is a patch (built against \{{branch_7x}}) that centralizes accesses
> to the {{tests.seed}} system property; it also makes sure that if it is
> empty, it is treated as absent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8146) Unit tests using StringHelper fail with ExceptionInInitializerError for maven surefire >= 2.18
[
https://issues.apache.org/jira/browse/LUCENE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16348253#comment-16348253
]
Julien Massenet commented on LUCENE-8146:
-
Dawid and Robert: this was actually not new code - this is just code that was
already present in the code-base, just duplicated:
*
[https://github.com/apache/lucene-solr/blob/branch_7x/solr/core/src/java/org/apache/solr/cloud/api/collections/OverseerCollectionMessageHandler.java#L174]
*
[https://github.com/apache/lucene-solr/blob/branch_7x/solr/core/src/java/org/apache/solr/core/BlobRepository.java#L56]
*
[https://github.com/apache/lucene-solr/blob/branch_7x/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L138]
I only added a class in an effort to reduce the duplication, but I did not
introduce that behavior (of using Random instead of the RandomizedContext).
I've attached a newer patch version which copy-paste the changes at all
affected locations instead. It is still using Random directly, as it was before.
For reference, here is the stacktrace you get when you encounter the issue:
{code:java}
breakingTest(org.apache.lucene.seed_issue.SomeClassUsingStringHelperTest) Time
elapsed: 0.006 s <<< ERROR!
java.lang.ExceptionInInitializerError
at
org.apache.lucene.seed_issue.SomeClassUsingStringHelperTest.breakingTest(SomeClassUsingStringHelperTest.java:10)
Caused by: java.lang.NumberFormatException: For input string: ""
at
org.apache.lucene.seed_issue.SomeClassUsingStringHelperTest.breakingTest(SomeClassUsingStringHelperTest.java:10){code}
(So no reference to the class in question, which made tracking down the issue
painful)
I didn't check the RandomizedRunner part, but one think to note in this case:
it seems like any error that would happen in RandomizedRunner would only affect
the Lucene unit tests or clients using the test framework, no ? Whereas the
problem with {{tests.seed}} parsing & {{StringHelper}} happens in production
code, so it impacts client code that depend on Lucene, even if it doesn't use
its test framework.
> Unit tests using StringHelper fail with ExceptionInInitializerError for maven
> surefire >= 2.18
> --
>
> Key: LUCENE-8146
> URL: https://issues.apache.org/jira/browse/LUCENE-8146
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.2.1
>Reporter: Julien Massenet
>Priority: Minor
> Attachments: LUCENE-8146-seed_issue.tar.gz, LUCENE-8146_v1.patch,
> LUCENE-8146_v2.patch
>
>
> This happens when multiple conditions are met:
> * The client code is built with Maven
> * To execute its unit tests, the client code relies on the
> {{maven-surefire-plugin}}, with a version greater than 2.17 (last working
> version)
> * The client code uses the {{org.apache.lucene.util.StringHelper}} class
> (even transitively)
> * The client is configured as with the standard Lucene maven build (i.e. it
> is possible to fix the test seed using the {{tests.seed}} property)
> There was a change in Surefire's behavior starting with 2.18: when a property
> is empty, instead of not sending it to the test runner, it will be sent with
> an empty value.
> This behavior can be observed with the attached sample project:
> * {{mvn test}}: fails with a {{java.lang.ExceptionInInitializerError}}
> * {{mvn test -Dtests.seed=123456}}: succeeds because the property is set to
> a real value
> * {{mvn test -Dsurefire.version=2.17}}: succeeds because the surefire
> version is lower than 2.18
> Attached is a patch (built against \{{branch_7x}}) that centralizes accesses
> to the {{tests.seed}} system property; it also makes sure that if it is
> empty, it is treated as absent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8146) Unit tests using StringHelper fail with ExceptionInInitializerError for maven surefire >= 2.18
[
https://issues.apache.org/jira/browse/LUCENE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien Massenet updated LUCENE-8146:
Attachment: LUCENE-8146_v2.patch
> Unit tests using StringHelper fail with ExceptionInInitializerError for maven
> surefire >= 2.18
> --
>
> Key: LUCENE-8146
> URL: https://issues.apache.org/jira/browse/LUCENE-8146
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.2.1
>Reporter: Julien Massenet
>Priority: Minor
> Attachments: LUCENE-8146-seed_issue.tar.gz, LUCENE-8146_v1.patch,
> LUCENE-8146_v2.patch
>
>
> This happens when multiple conditions are met:
> * The client code is built with Maven
> * To execute its unit tests, the client code relies on the
> {{maven-surefire-plugin}}, with a version greater than 2.17 (last working
> version)
> * The client code uses the {{org.apache.lucene.util.StringHelper}} class
> (even transitively)
> * The client is configured as with the standard Lucene maven build (i.e. it
> is possible to fix the test seed using the {{tests.seed}} property)
> There was a change in Surefire's behavior starting with 2.18: when a property
> is empty, instead of not sending it to the test runner, it will be sent with
> an empty value.
> This behavior can be observed with the attached sample project:
> * {{mvn test}}: fails with a {{java.lang.ExceptionInInitializerError}}
> * {{mvn test -Dtests.seed=123456}}: succeeds because the property is set to
> a real value
> * {{mvn test -Dsurefire.version=2.17}}: succeeds because the surefire
> version is lower than 2.18
> Attached is a patch (built against \{{branch_7x}}) that centralizes accesses
> to the {{tests.seed}} system property; it also makes sure that if it is
> empty, it is treated as absent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8146) Unit tests using StringHelper fail with ExceptionInInitializerError for maven surefire >= 2.18
[
https://issues.apache.org/jira/browse/LUCENE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347129#comment-16347129
]
Julien MASSENET commented on LUCENE-8146:
-
The patch itself is minimal, but I'll understand if the issue is just closed as
is - you're right that it's not a Lucene issue. On the other hand, the Lucene
maven build would also be impacted if the surefire version is ever bumped up,
as it will break with the same error.
I'm just throwing that out there since I spent about 30 minutes figuring out
why my build was failing after upgrading all my dependencies (that including
Lucene and other the surefire plugin). Even if the ticket is closed, it might
help the next user encountering the same problem.
> Unit tests using StringHelper fail with ExceptionInInitializerError for maven
> surefire >= 2.18
> --
>
> Key: LUCENE-8146
> URL: https://issues.apache.org/jira/browse/LUCENE-8146
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.2.1
>Reporter: Julien MASSENET
>Priority: Minor
> Attachments: LUCENE-8146-seed_issue.tar.gz, LUCENE-8146_v1.patch
>
>
> This happens when multiple conditions are met:
> * The client code is built with Maven
> * To execute its unit tests, the client code relies on the
> {{maven-surefire-plugin}}, with a version greater than 2.17 (last working
> version)
> * The client code uses the {{org.apache.lucene.util.StringHelper}} class
> (even transitively)
> * The client is configured as with the standard Lucene maven build (i.e. it
> is possible to fix the test seed using the {{tests.seed}} property)
> There was a change in Surefire's behavior starting with 2.18: when a property
> is empty, instead of not sending it to the test runner, it will be sent with
> an empty value.
> This behavior can be observed with the attached sample project:
> * {{mvn test}}: fails with a {{java.lang.ExceptionInInitializerError}}
> * {{mvn test -Dtests.seed=123456}}: succeeds because the property is set to
> a real value
> * {{mvn test -Dsurefire.version=2.17}}: succeeds because the surefire
> version is lower than 2.18
> Attached is a patch (built against \{{branch_7x}}) that centralizes accesses
> to the {{tests.seed}} system property; it also makes sure that if it is
> empty, it is treated as absent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8146) Unit tests using StringHelper fail with ExceptionInInitializerError for maven surefire >= 2.18
[
https://issues.apache.org/jira/browse/LUCENE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien MASSENET updated LUCENE-8146:
Description:
This happens when multiple conditions are met:
* The client code is built with Maven
* To execute its unit tests, the client code relies on the
{{maven-surefire-plugin}}, with a version greater than 2.17 (last working
version)
* The client code uses the {{org.apache.lucene.util.StringHelper}} class (even
transitively)
* The client is configured as with the standard Lucene maven build (i.e. it is
possible to fix the test seed using the {{tests.seed}} property)
There was a change in Surefire's behavior starting with 2.18: when a property
is empty, instead of not sending it to the test runner, it will be sent with an
empty value.
This behavior can be observed with the attached sample project:
* {{mvn test}}: fails with a {{java.lang.ExceptionInInitializerError}}
* {{mvn test -Dtests.seed=123456}}: succeeds because the property is set to a
real value
* {{mvn test -Dsurefire.version=2.17}}: succeeds because the surefire version
is lower than 2.18
Attached is a patch (built against \{{branch_7x}}) that centralizes accesses to
the {{tests.seed}} system property; it also makes sure that if it is empty, it
is treated as absent.
was:
This happens when multiple conditions are met:
* The client code is built with Maven
* To execute its unit tests, the client code relies on the
{{maven-surefire-plugin}}, with a version greater than 2.17 (last working
version)
* The client code uses the {{org.apache.lucene.util.StringHelper}} class (even
transitively)
* The client is configured as with the standard Lucene maven build (i.e. it is
possible to fix the test seed using the {{tests.seed}} property)
There was a change in Surefire's behavior starting with 2.18: when a property
is empty, instead of not sending it to the test runner, it will be sent with an
empty value.
This behavior can be observed with the attached sample project:
* {{mvn test}}: fails with a {{java.lang.ExceptionInInitializerError}}
* {{mvn test -Dtests.seed=123456}}: succeeds because the property is set to a
real value
* {{mvn test -Dsurefire.version=2.17}}: succeeds because the surefire version
is lower than 2.18
Attached is a patch that centralizes accesses to the {{tests.seed}} system
property; it also makes sure that if it is empty, it is treated as absent.
> Unit tests using StringHelper fail with ExceptionInInitializerError for maven
> surefire >= 2.18
> --
>
> Key: LUCENE-8146
> URL: https://issues.apache.org/jira/browse/LUCENE-8146
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.2.1
>Reporter: Julien MASSENET
>Priority: Minor
> Attachments: LUCENE-8146-seed_issue.tar.gz, LUCENE-8146_v1.patch
>
>
> This happens when multiple conditions are met:
> * The client code is built with Maven
> * To execute its unit tests, the client code relies on the
> {{maven-surefire-plugin}}, with a version greater than 2.17 (last working
> version)
> * The client code uses the {{org.apache.lucene.util.StringHelper}} class
> (even transitively)
> * The client is configured as with the standard Lucene maven build (i.e. it
> is possible to fix the test seed using the {{tests.seed}} property)
> There was a change in Surefire's behavior starting with 2.18: when a property
> is empty, instead of not sending it to the test runner, it will be sent with
> an empty value.
> This behavior can be observed with the attached sample project:
> * {{mvn test}}: fails with a {{java.lang.ExceptionInInitializerError}}
> * {{mvn test -Dtests.seed=123456}}: succeeds because the property is set to
> a real value
> * {{mvn test -Dsurefire.version=2.17}}: succeeds because the surefire
> version is lower than 2.18
> Attached is a patch (built against \{{branch_7x}}) that centralizes accesses
> to the {{tests.seed}} system property; it also makes sure that if it is
> empty, it is treated as absent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8146) Unit tests using StringHelper fail with ExceptionInInitializerError for maven surefire >= 2.18
[
https://issues.apache.org/jira/browse/LUCENE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien MASSENET updated LUCENE-8146:
Attachment: LUCENE-8146_v1.patch
> Unit tests using StringHelper fail with ExceptionInInitializerError for maven
> surefire >= 2.18
> --
>
> Key: LUCENE-8146
> URL: https://issues.apache.org/jira/browse/LUCENE-8146
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.2.1
>Reporter: Julien MASSENET
>Priority: Minor
> Attachments: LUCENE-8146-seed_issue.tar.gz, LUCENE-8146_v1.patch
>
>
> This happens when multiple conditions are met:
> * The client code is built with Maven
> * To execute its unit tests, the client code relies on the
> {{maven-surefire-plugin}}, with a version greater than 2.17 (last working
> version)
> * The client code uses the {{org.apache.lucene.util.StringHelper}} class
> (even transitively)
> * The client is configured as with the standard Lucene maven build (i.e. it
> is possible to fix the test seed using the {{tests.seed}} property)
> There was a change in Surefire's behavior starting with 2.18: when a property
> is empty, instead of not sending it to the test runner, it will be sent with
> an empty value.
> This behavior can be observed with the attached sample project:
> * {{mvn test}}: fails with a {{java.lang.ExceptionInInitializerError}}
> * {{mvn test -Dtests.seed=123456}}: succeeds because the property is set to
> a real value
> * {{mvn test -Dsurefire.version=2.17}}: succeeds because the surefire
> version is lower than 2.18
> Attached is a patch that centralizes accesses to the {{tests.seed}} system
> property; it also makes sure that if it is empty, it is treated as absent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8146) Unit tests using StringHelper fail with ExceptionInInitializerError for maven surefire >= 2.18
[
https://issues.apache.org/jira/browse/LUCENE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien MASSENET updated LUCENE-8146:
Attachment: LUCENE-8146-seed_issue.tar.gz
> Unit tests using StringHelper fail with ExceptionInInitializerError for maven
> surefire >= 2.18
> --
>
> Key: LUCENE-8146
> URL: https://issues.apache.org/jira/browse/LUCENE-8146
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.2.1
>Reporter: Julien MASSENET
>Priority: Minor
> Attachments: LUCENE-8146-seed_issue.tar.gz
>
>
> This happens when multiple conditions are met:
> * The client code is built with Maven
> * To execute its unit tests, the client code relies on the
> {{maven-surefire-plugin}}, with a version greater than 2.17 (last working
> version)
> * The client code uses the {{org.apache.lucene.util.StringHelper}} class
> (even transitively)
> * The client is configured as with the standard Lucene maven build (i.e. it
> is possible to fix the test seed using the {{tests.seed}} property)
> There was a change in Surefire's behavior starting with 2.18: when a property
> is empty, instead of not sending it to the test runner, it will be sent with
> an empty value.
> This behavior can be observed with the attached sample project:
> * {{mvn test}}: fails with a {{java.lang.ExceptionInInitializerError}}
> * {{mvn test -Dtests.seed=123456}}: succeeds because the property is set to
> a real value
> * {{mvn test -Dsurefire.version=2.17}}: succeeds because the surefire
> version is lower than 2.18
> Attached is a patch that centralizes accesses to the {{tests.seed}} system
> property; it also makes sure that if it is empty, it is treated as absent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8146) Unit tests using StringHelper fail with ExceptionInInitializerError for maven surefire >= 2.18
Julien MASSENET created LUCENE-8146:
---
Summary: Unit tests using StringHelper fail with
ExceptionInInitializerError for maven surefire >= 2.18
Key: LUCENE-8146
URL: https://issues.apache.org/jira/browse/LUCENE-8146
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 7.2.1
Reporter: Julien MASSENET
This happens when multiple conditions are met:
* The client code is built with Maven
* To execute its unit tests, the client code relies on the
{{maven-surefire-plugin}}, with a version greater than 2.17 (last working
version)
* The client code uses the {{org.apache.lucene.util.StringHelper}} class (even
transitively)
* The client is configured as with the standard Lucene maven build (i.e. it is
possible to fix the test seed using the {{tests.seed}} property)
There was a change in Surefire's behavior starting with 2.18: when a property
is empty, instead of not sending it to the test runner, it will be sent with an
empty value.
This behavior can be observed with the attached sample project:
* {{mvn test}}: fails with a {{java.lang.ExceptionInInitializerError}}
* {{mvn test -Dtests.seed=123456}}: succeeds because the property is set to a
real value
* {{mvn test -Dsurefire.version=2.17}}: succeeds because the surefire version
is lower than 2.18
Attached is a patch that centralizes accesses to the {{tests.seed}} system
property; it also makes sure that if it is empty, it is treated as absent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8441) maxScore is sometimes missing from distributed grouped responses
[
https://issues.apache.org/jira/browse/SOLR-8441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien MASSENET updated SOLR-8441:
--
Attachment: master-GroupingMaxScore.patch
Hi,
The same patch applies cleanly on the current master as well. Still, I've added
a version based on the latest {{master}} to the page.
> maxScore is sometimes missing from distributed grouped responses
>
>
> Key: SOLR-8441
> URL: https://issues.apache.org/jira/browse/SOLR-8441
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 5.3
>Reporter: Julien MASSENET
>Priority: Minor
> Attachments: lucene_6_5-GroupingMaxScore.patch,
> lucene_solr_5_3-GroupingMaxScore.patch, master-GroupingMaxScore.patch
>
>
> This issue occurs when using the grouping feature in distributed mode and
> sorting by score.
> Each group's {{docList}} in the response is supposed to contain a
> {{maxScore}} entry that hold the maximum score for that group. Using the
> current releases, it sometimes happens that this piece of information is not
> included:
> {code}
> {
> "responseHeader": {
> "status": 0,
> "QTime": 42,
> "params": {
> "sort": "score desc",
> "fl": "id,score",
> "q": "_text_:\"72\"",
> "group.limit": "2",
> "group.field": "group2",
> "group.sort": "score desc",
> "group": "true",
> "wt": "json",
> "fq": "group2:72 OR group2:45"
> }
> },
> "grouped": {
> "group2": {
> "matches": 567,
> "groups": [
> {
> "groupValue": 72,
> "doclist": {
> "numFound": 562,
> "start": 0,
> "maxScore": 2.0378063,
> "docs": [
> {
> "id": "29!26551",
> "score": 2.0378063
> },
> {
> "id": "78!11462",
> "score": 2.0298104
> }
> ]
> }
> },
> {
> "groupValue": 45,
> "doclist": {
> "numFound": 5,
> "start": 0,
> "docs": [
> {
> "id": "72!8569",
> "score": 1.8988966
> },
> {
> "id": "72!14075",
> "score": 1.5191172
> }
> ]
> }
> }
> ]
> }
> }
> }
> {code}
> Looking into the issue, it comes from the fact that if a shard does not
> contain a document from that group, trying to merge its {{maxScore}} with
> real {{maxScore}} entries from other shards is invalid (it results in NaN).
> I'm attaching a patch containing a fix.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8441) maxScore is sometimes missing from distributed grouped responses
[
https://issues.apache.org/jira/browse/SOLR-8441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien MASSENET updated SOLR-8441:
--
Attachment: lucene_6_5-GroupingMaxScore.patch
Hi !
This issue is still happening to me in the newer Solr versions. I'm attaching
an updated patch that runs against the current (as of 2017-03-06) {{branch_6x}}
head.
> maxScore is sometimes missing from distributed grouped responses
>
>
> Key: SOLR-8441
> URL: https://issues.apache.org/jira/browse/SOLR-8441
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 5.3
>Reporter: Julien MASSENET
>Priority: Minor
> Attachments: lucene_6_5-GroupingMaxScore.patch,
> lucene_solr_5_3-GroupingMaxScore.patch
>
>
> This issue occurs when using the grouping feature in distributed mode and
> sorting by score.
> Each group's {{docList}} in the response is supposed to contain a
> {{maxScore}} entry that hold the maximum score for that group. Using the
> current releases, it sometimes happens that this piece of information is not
> included:
> {code}
> {
> "responseHeader": {
> "status": 0,
> "QTime": 42,
> "params": {
> "sort": "score desc",
> "fl": "id,score",
> "q": "_text_:\"72\"",
> "group.limit": "2",
> "group.field": "group2",
> "group.sort": "score desc",
> "group": "true",
> "wt": "json",
> "fq": "group2:72 OR group2:45"
> }
> },
> "grouped": {
> "group2": {
> "matches": 567,
> "groups": [
> {
> "groupValue": 72,
> "doclist": {
> "numFound": 562,
> "start": 0,
> "maxScore": 2.0378063,
> "docs": [
> {
> "id": "29!26551",
> "score": 2.0378063
> },
> {
> "id": "78!11462",
> "score": 2.0298104
> }
> ]
> }
> },
> {
> "groupValue": 45,
> "doclist": {
> "numFound": 5,
> "start": 0,
> "docs": [
> {
> "id": "72!8569",
> "score": 1.8988966
> },
> {
> "id": "72!14075",
> "score": 1.5191172
> }
> ]
> }
> }
> ]
> }
> }
> }
> {code}
> Looking into the issue, it comes from the fact that if a shard does not
> contain a document from that group, trying to merge its {{maxScore}} with
> real {{maxScore}} entries from other shards is invalid (it results in NaN).
> I'm attaching a patch containing a fix.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9694) PostFilters' DelegatingCollector.finish() is not called during first and second grouping phases
[
https://issues.apache.org/jira/browse/SOLR-9694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien MASSENET updated SOLR-9694:
--
Attachment: SOLR-9694-v1.patch
Attached patch {{SOLR-9694-v1.patch}} was built against the
{{releases/lucene-solr/6.2.1}} tag
> PostFilters' DelegatingCollector.finish() is not called during first and
> second grouping phases
> ---
>
> Key: SOLR-9694
> URL: https://issues.apache.org/jira/browse/SOLR-9694
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Affects Versions: 6.2.1
>Reporter: Julien MASSENET
>Priority: Minor
> Attachments: SOLR-9694-v1.patch
>
>
> The {{finish()}} method has been added to {{DelegatingCollector}} as part of
> SOLR-5020.
> Grouping has been updated to call it by SOLR-5230.
> Some calls made during the grouping process fail to call the {{finish()}}
> method even thought they properly call the {{collect()}} one.
> I'm attaching a patch with updated tests that reproduce the issue, as well as
> a candidate fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9694) PostFilters' DelegatingCollector.finish() is not called during first and second grouping phases
Julien MASSENET created SOLR-9694:
-
Summary: PostFilters' DelegatingCollector.finish() is not called
during first and second grouping phases
Key: SOLR-9694
URL: https://issues.apache.org/jira/browse/SOLR-9694
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: search
Affects Versions: 6.2.1
Reporter: Julien MASSENET
Priority: Minor
The {{finish()}} method has been added to {{DelegatingCollector}} as part of
SOLR-5020.
Grouping has been updated to call it by SOLR-5230.
Some calls made during the grouping process fail to call the {{finish()}}
method even thought they properly call the {{collect()}} one.
I'm attaching a patch with updated tests that reproduce the issue, as well as a
candidate fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7456) PerField(DocValues|Postings)Format do not call the per-field merge methods
[ https://issues.apache.org/jira/browse/LUCENE-7456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien MASSENET updated LUCENE-7456: Attachment: LUCENE-7456-v2.patch > PerField(DocValues|Postings)Format do not call the per-field merge methods > -- > > Key: LUCENE-7456 > URL: https://issues.apache.org/jira/browse/LUCENE-7456 > Project: Lucene - Core > Issue Type: Bug > Components: core/codecs >Affects Versions: 6.2.1 >Reporter: Julien MASSENET > Attachments: LUCENE-7456-v2.patch, LUCENE-7456.patch > > > While porting some old codec code from Lucene 4.3.1, I couldn't get the > per-field formats to call upon the per-field merge methods; the default merge > method was always being called. > I think this is a side-effect of LUCENE-5894. > Attached is a patch with a test that reproduces the error and an associated > fix that pass the unit tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7456) PerField(DocValues|Postings)Format do not call the per-field merge methods
[
https://issues.apache.org/jira/browse/LUCENE-7456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15526416#comment-15526416
]
Julien MASSENET commented on LUCENE-7456:
-
I agree that being this sneaky is not ideal, but the only alternative I see
would be change the Postings API.
In this patch, I tried to keep modifications constrained to the
{{org.apache.lucene.codecs.perfield}} package, but I can give a shot at trying
to a come up with a cleaner implementation that updates the other APIs if you
want.
I've uploaded an updated version of the patch which does not remove the
sneakiness but makes the {{PerFieldMergeState}} more robust:
* The {{FilterFieldInfos}} class now correctly computes and exposes the
{{hasXXX}} properties.
* Calls to {{FilterFieldInfos.fieldInfo()}} and
{{FilterFieldsProducer.terms()}} now throw {{IllegalArgumentException}} if
called with fields outside if the current merge context
* I've tweaked the unit tests to work with the latest 6.2.1 since the
{{Legacy*}} field types are not accessible in this module anymore.
As for why we're overriding merge() calls in our codec:
* We're using a customized codec to emulate nested documents.
* It works with the same idea as BlockJoin, but is less generic (it's tailored
to our use case).
* The main difference is that the maxDoc() for segments remain equal to the
number of "parent" documents, with only the nested fields having larger posting
lists.
* For it to work, when merging, we need to rebase correctly the "docIds" for
the nested documents (using the same idea as the docMap in the general use
case).
> PerField(DocValues|Postings)Format do not call the per-field merge methods
> --
>
> Key: LUCENE-7456
> URL: https://issues.apache.org/jira/browse/LUCENE-7456
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/codecs
>Affects Versions: 6.2.1
>Reporter: Julien MASSENET
> Attachments: LUCENE-7456-v2.patch, LUCENE-7456.patch
>
>
> While porting some old codec code from Lucene 4.3.1, I couldn't get the
> per-field formats to call upon the per-field merge methods; the default merge
> method was always being called.
> I think this is a side-effect of LUCENE-5894.
> Attached is a patch with a test that reproduces the error and an associated
> fix that pass the unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7456) PerField(DocValues|Postings)Format do not call the per-field merge methods
[ https://issues.apache.org/jira/browse/LUCENE-7456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien MASSENET updated LUCENE-7456: Attachment: LUCENE-7456.patch > PerField(DocValues|Postings)Format do not call the per-field merge methods > -- > > Key: LUCENE-7456 > URL: https://issues.apache.org/jira/browse/LUCENE-7456 > Project: Lucene - Core > Issue Type: Bug > Components: core/codecs >Affects Versions: 6.2.1 >Reporter: Julien MASSENET > Attachments: LUCENE-7456.patch > > > While porting some old codec code from Lucene 4.3.1, I couldn't get the > per-field formats to call upon the per-field merge methods; the default merge > method was always being called. > I think this is a side-effect of LUCENE-5894. > Attached is a patch with a test that reproduces the error and an associated > fix that pass the unit tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7456) PerField(DocValues|Postings)Format do not call the per-field merge methods
Julien MASSENET created LUCENE-7456: --- Summary: PerField(DocValues|Postings)Format do not call the per-field merge methods Key: LUCENE-7456 URL: https://issues.apache.org/jira/browse/LUCENE-7456 Project: Lucene - Core Issue Type: Bug Components: core/codecs Affects Versions: 6.2.1 Reporter: Julien MASSENET While porting some old codec code from Lucene 4.3.1, I couldn't get the per-field formats to call upon the per-field merge methods; the default merge method was always being called. I think this is a side-effect of LUCENE-5894. Attached is a patch with a test that reproduces the error and an associated fix that pass the unit tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8441) maxScore is sometimes missing from distributed grouped responses
[
https://issues.apache.org/jira/browse/SOLR-8441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien MASSENET updated SOLR-8441:
--
Attachment: lucene_solr_5_3-GroupingMaxScore.patch
> maxScore is sometimes missing from distributed grouped responses
>
>
> Key: SOLR-8441
> URL: https://issues.apache.org/jira/browse/SOLR-8441
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 5.3
>Reporter: Julien MASSENET
>Priority: Minor
> Attachments: lucene_solr_5_3-GroupingMaxScore.patch
>
>
> This issue occurs when using the grouping feature in distributed mode and
> sorting by score.
> Each group's {{docList}} in the response is supposed to contain a
> {{maxScore}} entry that hold the maximum score for that group. Using the
> current releases, it sometimes happens that this piece of information is not
> included:
> {code}
> {
> "responseHeader": {
> "status": 0,
> "QTime": 42,
> "params": {
> "sort": "score desc",
> "fl": "id,score",
> "q": "_text_:\"72\"",
> "group.limit": "2",
> "group.field": "group2",
> "group.sort": "score desc",
> "group": "true",
> "wt": "json",
> "fq": "group2:72 OR group2:45"
> }
> },
> "grouped": {
> "group2": {
> "matches": 567,
> "groups": [
> {
> "groupValue": 72,
> "doclist": {
> "numFound": 562,
> "start": 0,
> "maxScore": 2.0378063,
> "docs": [
> {
> "id": "29!26551",
> "score": 2.0378063
> },
> {
> "id": "78!11462",
> "score": 2.0298104
> }
> ]
> }
> },
> {
> "groupValue": 45,
> "doclist": {
> "numFound": 5,
> "start": 0,
> "docs": [
> {
> "id": "72!8569",
> "score": 1.8988966
> },
> {
> "id": "72!14075",
> "score": 1.5191172
> }
> ]
> }
> }
> ]
> }
> }
> }
> {code}
> Looking into the issue, it comes from the fact that if a shard does not
> contain a document from that group, trying to merge its {{maxScore}} with
> real {{maxScore}} entries from other shards is invalid (it results in NaN).
> I'm attaching a patch containing a fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8441) maxScore is sometimes missing from distributed grouped responses
[
https://issues.apache.org/jira/browse/SOLR-8441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien MASSENET updated SOLR-8441:
--
Flags: Patch
Description:
This issue occurs when using the grouping feature in distributed mode and
sorting by score.
Each group's {{docList}} in the response is supposed to contain a {{maxScore}}
entry that hold the maximum score for that group. Using the current releases,
it sometimes happens that this piece of information is not included:
{code}
{
"responseHeader": {
"status": 0,
"QTime": 42,
"params": {
"sort": "score desc",
"fl": "id,score",
"q": "_text_:\"72\"",
"group.limit": "2",
"group.field": "group2",
"group.sort": "score desc",
"group": "true",
"wt": "json",
"fq": "group2:72 OR group2:45"
}
},
"grouped": {
"group2": {
"matches": 567,
"groups": [
{
"groupValue": 72,
"doclist": {
"numFound": 562,
"start": 0,
"maxScore": 2.0378063,
"docs": [
{
"id": "29!26551",
"score": 2.0378063
},
{
"id": "78!11462",
"score": 2.0298104
}
]
}
},
{
"groupValue": 45,
"doclist": {
"numFound": 5,
"start": 0,
"docs": [
{
"id": "72!8569",
"score": 1.8988966
},
{
"id": "72!14075",
"score": 1.5191172
}
]
}
}
]
}
}
}
{code}
Looking into the issue, it comes from the fact that if a shard does not contain
a document from that group, trying to merge its {{maxScore}} with real
{{maxScore}} entries from other shards is invalid (it results in NaN).
I'm attaching a patch containing a fix.
was:
This issue occurs when using the grouping feature in distributed mode and
sorting by score.
Each group's {{docList}} in the response is supposed to contain a {{maxScore}}
entry that hold the maximum score for that group. Using the current releases,
it sometimes happens that this piece of information is not included:
{code}
> maxScore is sometimes missing from distributed grouped responses
>
>
> Key: SOLR-8441
> URL: https://issues.apache.org/jira/browse/SOLR-8441
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 5.3
>Reporter: Julien MASSENET
>Priority: Minor
>
> This issue occurs when using the grouping feature in distributed mode and
> sorting by score.
> Each group's {{docList}} in the response is supposed to contain a
> {{maxScore}} entry that hold the maximum score for that group. Using the
> current releases, it sometimes happens that this piece of information is not
> included:
> {code}
> {
> "responseHeader": {
> "status": 0,
> "QTime": 42,
> "params": {
> "sort": "score desc",
> "fl": "id,score",
> "q": "_text_:\"72\"",
> "group.limit": "2",
> "group.field": "group2",
> "group.sort": "score desc",
> "group": "true",
> "wt": "json",
> "fq": "group2:72 OR group2:45"
> }
> },
> "grouped": {
> "group2": {
> "matches": 567,
> "groups": [
> {
> "groupValue": 72,
> "doclist": {
> "numFound": 562,
> "start": 0,
> "maxScore": 2.0378063,
> "docs": [
> {
> "id": "29!26551",
> "score": 2.0378063
> },
> {
> "id": "78!11462",
> "score": 2.0298104
> }
> ]
> }
> },
> {
> "groupValue": 45,
> "doclist": {
> "numFound": 5,
> "start": 0,
> "docs": [
> {
> "id": "72!8569",
> "score": 1.8988966
> },
> {
> "id": "72!14075",
> "score": 1.5191172
> }
> ]
> }
> }
> ]
> }
> }
> }
> {code}
> Looking into the issue, it comes from the fact that if a shard does not
> contain a document from that group, trying to merge its {{maxScore}} with
> real {{maxScore}} entries from other shards is invalid (it results in NaN).
> I'm attaching a patch containing a fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@luc
[jira] [Created] (SOLR-8441) maxScore is sometimes missing from distributed grouped responses
Julien MASSENET created SOLR-8441:
-
Summary: maxScore is sometimes missing from distributed grouped
responses
Key: SOLR-8441
URL: https://issues.apache.org/jira/browse/SOLR-8441
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 5.3
Reporter: Julien MASSENET
Priority: Minor
This issue occurs when using the grouping feature in distributed mode and
sorting by score.
Each group's {{docList}} in the response is supposed to contain a {{maxScore}}
entry that hold the maximum score for that group. Using the current releases,
it sometimes happens that this piece of information is not included:
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
