[jira] [Updated] (LUCENE-8793) Enhanced UI for CustomAnalyzer : show analysis steps
[
https://issues.apache.org/jira/browse/LUCENE-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-8793:
--
Attachment: Screenshot from 2019-05-06 13-45-40.png
> Enhanced UI for CustomAnalyzer : show analysis steps
>
>
> Key: LUCENE-8793
> URL: https://issues.apache.org/jira/browse/LUCENE-8793
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/luke
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: LUCENE-8793.patch, Screen Shot 2019-05-06 at
> 10.00.57.png, Screenshot from 2019-05-06 13-45-40.png, Screenshot from
> 2019-05-06 13-46-16.png
>
>
> This is a migrated issue from previous Luke project in GitHub:
> [https://github.com/DmitryKey/luke/issues/134]
>
> For on-the-fly inspection / debugging, it is desirable to show the more
> detailed step by step information in the Custom Analyzer UI.
> This will be just like Solr's Analysis screen,
> [https://lucene.apache.org/solr/guide/7_5/analysis-screen.html]
> or Elasticsearch's {{_analyze}} API and Kibana's Analyzer UI.
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html]
> [https://github.com/johtani/analyze-api-ui-plugin]
--
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-8793) Enhanced UI for CustomAnalyzer : show analysis steps
[
https://issues.apache.org/jira/browse/LUCENE-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-8793:
--
Attachment: Screenshot from 2019-05-06 13-46-16.png
> Enhanced UI for CustomAnalyzer : show analysis steps
>
>
> Key: LUCENE-8793
> URL: https://issues.apache.org/jira/browse/LUCENE-8793
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/luke
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: LUCENE-8793.patch, Screen Shot 2019-05-06 at
> 10.00.57.png, Screenshot from 2019-05-06 13-45-40.png, Screenshot from
> 2019-05-06 13-46-16.png
>
>
> This is a migrated issue from previous Luke project in GitHub:
> [https://github.com/DmitryKey/luke/issues/134]
>
> For on-the-fly inspection / debugging, it is desirable to show the more
> detailed step by step information in the Custom Analyzer UI.
> This will be just like Solr's Analysis screen,
> [https://lucene.apache.org/solr/guide/7_5/analysis-screen.html]
> or Elasticsearch's {{_analyze}} API and Kibana's Analyzer UI.
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html]
> [https://github.com/johtani/analyze-api-ui-plugin]
--
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
[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk-11.0.2) - Build # 201 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/201/ Java: 64bit/jdk-11.0.2 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 2000 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/build/core/test/temp/junit4-J2-20190506_032655_59712240963456019556145.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [...truncated 10 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/build/core/test/temp/junit4-J1-20190506_032655_59714254749997391751064.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/build/core/test/temp/junit4-J0-20190506_032655_59710168419225650219232.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 304 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/build/test-framework/test/temp/junit4-J1-20190506_033811_29114651360626737602436.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/build/test-framework/test/temp/junit4-J0-20190506_033811_291201199257205605086.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/build/test-framework/test/temp/junit4-J2-20190506_033811_29215522129248699871376.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [...truncated 1075 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/build/analysis/common/test/temp/junit4-J1-20190506_033952_40710315978221203410036.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 3 lines...] [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/build/analysis/common/test/temp/junit4-J0-20190506_033952_4079130869095366320730.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/build/analysis/common/test/temp/junit4-J2-20190506_033952_4073671253765073205550.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [...truncated 241 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/lucene/build/analysis/icu/test/temp/junit4-J2-20190506_034235_628182402688126492601.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see:
Re: Call for help: moving from ant build to gradle
I agree that an easier-to-understand build is an important virtue we should try to achieve here (for the reasons you mentioned). Our build is too complex and non-standard. Any other benefits are icing on the cake. RE "side by side"; that could weigh us down maintaining more; I hope this isn't long term. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Sun, May 5, 2019 at 6:23 PM Mark Miller wrote: > We can indeed make them work side by side. > > - Mark > > On Sun, May 5, 2019 at 11:36 AM Erick Erickson > wrote: > >> I don’t know enough about the differences to even think consider >> complaining. >> >> Is the proposal that we use Gradle for master and continue to use ant for >> 8x? As long as the two build systems can exist side by side (i.e. we can >> build master by executing some Gradle target and continue to build 8x with >> Ant like we always have) the minor inconvenience doesn’t merit standing in >> the way of progress. >> >> If that’s the case I don’t particularly care if we continue to use Ant >> with 8x forever. Or maybe some ambitious person can work on bringing 8x to >> Gradle after it has some mileage on master. >> >> And I have great faith that you wouldn’t be putting in the work unless >> you thought it was worth it ;) >> >> Erick >> >> > On May 4, 2019, at 10:31 PM, Mark Miller wrote: >> > >> > We already dump out to groovy to do anything interesting, so I doubt >> there is much we can't replicate. >> > >> > - Mark >> > >> > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com> wrote: >> > Would beasting of tests be possible through gradle? >> > >> > On Sun, May 5, 2019 at 7:33 AM Mark Miller >> wrote: >> > > >> > > I looked into this a little more. >> > > >> > > Seems if we just do it with master and going forward, we don’t need >> multi version support - Uwe seems to have taken it out with the move to >> Java 11? >> > > >> > > I can handle regenerate. >> > > >> > > The other quality checks shouldn’t be crazy. >> > > >> > > So I guess we can probably do this, but before I focus on BS details, >> please speak up if you hate the idea of Gradle and you have the clout to >> stop it. >> > > >> > > >> > > Mark >> > > >> > > >> > > >> > > >> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller >> wrote: >> > >> >> > >> I've got my own lucene-solr gradle branch as well. >> > >> >> > >> I stole the BuildPlugin and CheckWorkingCopy from Dat's branch, but >> also made some changes. >> > >> >> > >> * Similar to above above, I don't move the src files so it can keep >> things up to date without lots of pain. >> > >> * I used a plugin that lets us define versions in a root props file >> like we currently do and ensures we use the same versions in all modules >> even after auto conflict resolution (unlike gradle by default) >> > >> * It also locks versions so we can continue to pay attention to >> scary automatic dependency resolution changes >> > >> * implementation and api used instead of compile >> > >> * Things build and the majority of tests pass (Lucene's >> TestVirtualMethod does not for example) >> > >> >> > >> If someone like Uwe is serious about helping out with fun extras >> (regenerating sources, extracting data from ICU, quality checks, >> documentation (XSLT)), I'd look at contributing. >> > >> >> > >> - Mark >> > >> >> > >> >> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh >> wrote: >> > >>> >> > >>> Cool Diego, >> > >>> >> > >>> I will take a look on this. Thanks a lot! >> > >> >> > >> >> > >> >> > >> -- >> > >> - Mark >> > >> >> > >> http://about.me/markrmiller >> > > >> > > -- >> > > - Mark >> > > >> > > http://about.me/markrmiller >> > >> > >> > -- >> > - Mark >> > >> > http://about.me/markrmiller >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > -- > - Mark > > http://about.me/markrmiller >
[jira] [Commented] (SOLR-12562) Remove redundant RealTimeGetCompnent.toSolrDoc and use DocStreamer.convertLuceneDocToSolrDoc
[ https://issues.apache.org/jira/browse/SOLR-12562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833526#comment-16833526 ] David Smiley commented on SOLR-12562: - It's not clear how the field might not be in the schema (and tests didn't uncover it or you would have said). Should this happen (and we should add a comment that this is really unexpected), I think we could simply call f.stringValue() -- this is after all what SchemaField.toObject does by default. This will also work if the field is a number. I think I'm really leaning on consistently converting IndexableField to the opposite of this. > Remove redundant RealTimeGetCompnent.toSolrDoc and use > DocStreamer.convertLuceneDocToSolrDoc > > > Key: SOLR-12562 > URL: https://issues.apache.org/jira/browse/SOLR-12562 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-12562.patch > > > This code looks really redundant so we should remove one. The one in > RealTimeGet is the only used locally so my vote is to remove that one. -- 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] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833520#comment-16833520
]
ASF subversion and git services commented on SOLR-13318:
Commit 538b450236367907b4ab75852ca6d44032ac670b in lucene-solr's branch
refs/heads/branch_8_1 from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=538b450 ]
SOLR-13318: Fix casting issues in BucketBasedJsonFacet
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
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] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833518#comment-16833518
]
ASF subversion and git services commented on SOLR-13318:
Commit 919b0854448174c626c9ffc7c11770ae2477b210 in lucene-solr's branch
refs/heads/branch_8x from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=919b085 ]
SOLR-13318: Fix casting issues in BucketBasedJsonFacet
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
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] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833516#comment-16833516
]
ASF subversion and git services commented on SOLR-13318:
Commit 4309c6eca474e41811fe8fbbee10b501dfe60f93 in lucene-solr's branch
refs/heads/master from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4309c6e ]
SOLR-13318: Fix casting issues in BucketBasedJsonFacet
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
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] (SOLR-12562) Remove redundant RealTimeGetCompnent.toSolrDoc and use DocStreamer.convertLuceneDocToSolrDoc
[
https://issues.apache.org/jira/browse/SOLR-12562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833509#comment-16833509
]
Erick Erickson commented on SOLR-12562:
---
I can take the calls to *materialize()* out and the two test cases pass
(haven't tried a full test suite), but
That requires that we always get a non-null from
{code}
SchemaField sf = schema.getFieldOrNull(f.name());
{code}
The code explicitly tests for a null return in several cases, so this doesn't
seem safe.
*materialize()* doesn't require a SchemaField at all.
> Remove redundant RealTimeGetCompnent.toSolrDoc and use
> DocStreamer.convertLuceneDocToSolrDoc
>
>
> Key: SOLR-12562
> URL: https://issues.apache.org/jira/browse/SOLR-12562
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-12562.patch
>
>
> This code looks really redundant so we should remove one. The one in
> RealTimeGet is the only used locally so my vote is to remove that one.
--
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
[JENKINS-EA] Lucene-Solr-8.x-Linux (64bit/jdk-13-ea+18) - Build # 520 - Unstable!
Error processing tokens: Error while parsing action 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input position (line 79, pos 4): )"} ^ java.lang.OutOfMemoryError: Java heap space - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13320) add a param ignoreVersionConflicts=true to updates to not overwrite existing docs
[
https://issues.apache.org/jira/browse/SOLR-13320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833508#comment-16833508
]
Noble Paul commented on SOLR-13320:
---
I've updated the patch to use `failOnVersionConflicts=false` and the ref guide
is updated as well
> add a param ignoreVersionConflicts=true to updates to not overwrite existing
> docs
> -
>
> Key: SOLR-13320
> URL: https://issues.apache.org/jira/browse/SOLR-13320
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-13320.patch, SOLR-13320.patch, SOLR-13320.patch
>
>
> Updates should have an option to ignore duplicate documents and drop them if
> an option {{ignoreDuplicates=true}} is specified
--
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
[JENKINS-MAVEN] Lucene-Solr-Maven-master #2556: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-master/2556/ No tests ran. Build Log: [...truncated 18056 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:673: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:209: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/build.xml:408: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:1709: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:581: Error deploying artifact 'org.apache.lucene:lucene-core:jar': Error installing artifact's metadata: Error while deploying metadata: Error transferring file Total time: 9 minutes 4 seconds Build step 'Invoke Ant' marked build as failure Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 94 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/94/ 1 tests failed. FAILED: org.apache.solr.security.AuditLoggerIntegrationTest.testQueuedTimeMetric Error Message: Expecting mean time on queue >10ms, got 1.0002 Stack Trace: java.lang.AssertionError: Expecting mean time on queue >10ms, got 1.0002 at __randomizedtesting.SeedInfo.seed([41B4EB377A4CD73:2DA8565B3BD1FE2]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.apache.solr.security.AuditLoggerIntegrationTest.testQueuedTimeMetric(AuditLoggerIntegrationTest.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 12914 lines...] [junit4] Suite: org.apache.solr.security.AuditLoggerIntegrationTest [junit4] 2> Creating dataDir:
[jira] [Commented] (SOLR-12562) Remove redundant RealTimeGetCompnent.toSolrDoc and use DocStreamer.convertLuceneDocToSolrDoc
[ https://issues.apache.org/jira/browse/SOLR-12562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833483#comment-16833483 ] Erick Erickson commented on SOLR-12562: --- [~dsmiley] Thanks for the feedback. For all the two methods look similar, they are _just_ enough different to need to be separate. I'll give a whirl at removing the materialize all together. I like the idea of going through something common rather than the one-off in RealTimeGetComponent... > Remove redundant RealTimeGetCompnent.toSolrDoc and use > DocStreamer.convertLuceneDocToSolrDoc > > > Key: SOLR-12562 > URL: https://issues.apache.org/jira/browse/SOLR-12562 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-12562.patch > > > This code looks really redundant so we should remove one. The one in > RealTimeGet is the only used locally so my vote is to remove that one. -- 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-8793) Enhanced UI for CustomAnalyzer : show analysis steps
[
https://issues.apache.org/jira/browse/LUCENE-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833481#comment-16833481
]
Jun Ohtani commented on LUCENE-8793:
!Screen Shot 2019-05-06 at 10.00.57.png|width=672,height=365!
I've added new button "Test Analyzer Step By Step" for analyzing text by
tokenizer & filters step by step.
Also I've added new table in the lower panel for visualizing each
tokenizer/filters results.
If click the cell, pop up the dialog that you can see every attributes.
I attached the patch file for adding this feature.
Restriction:
Current patch is only show each tokenizer/filters result independently, so the
result doesn't show deletion/separation by next filter, e.g. "library" by
WordDelimiterFilter is different position between other output.
> Enhanced UI for CustomAnalyzer : show analysis steps
>
>
> Key: LUCENE-8793
> URL: https://issues.apache.org/jira/browse/LUCENE-8793
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/luke
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: LUCENE-8793.patch, Screen Shot 2019-05-06 at 10.00.57.png
>
>
> This is a migrated issue from previous Luke project in GitHub:
> [https://github.com/DmitryKey/luke/issues/134]
>
> For on-the-fly inspection / debugging, it is desirable to show the more
> detailed step by step information in the Custom Analyzer UI.
> This will be just like Solr's Analysis screen,
> [https://lucene.apache.org/solr/guide/7_5/analysis-screen.html]
> or Elasticsearch's {{_analyze}} API and Kibana's Analyzer UI.
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html]
> [https://github.com/johtani/analyze-api-ui-plugin]
--
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
Re: Socket Timeouts
Gus:
I’d _really_ like this all to be in one place, so fire away. We’ve spent far
too much time working with clients and wondering “where the hell are the
timeouts for XYZ?”
IMO, they should _all_ be configurable in a single place, preferably sorl.xml.
If you’re ambitious, a few comments in solr.xml about what the various
parameters actually control would be super-welcome.
Best
Erick@CheeringYouOnWhileNotDoingTheWork…
> On May 5, 2019, at 11:39 AM, Kevin Risden wrote:
>
> You might be interested in:
>
> https://issues.apache.org/jira/browse/SOLR-13389
>
>
> Kevin Risden
>
>
> On Sun, May 5, 2019 at 1:35 PM Gus Heck wrote:
> I'm working with a client that's trying to process a lot of data (billions of
> docs) via a streaming expression, and the initial query is (not surprisingly)
> taking a long time. Lots of various types of timeouts have been cropping up
> and I've found myself thinking I solved some only to discover that the
> settings in solr.xml are far less wide reaching than I thought initially. The
> present 5% scale cluster seems to hit one particular time out about 50% of
> the time which has made it particularly confusing. I'm guessing it's probably
> depending on something like how busy the virtualization in Amazon is, just
> barely making it when it gets more resources and timing out if anything is
> starved.
>
> As I look around the code base I'm finding a LOT of places where timeouts on
> SolrClients and CloudSolrClients are just arbitrarily set to one-off constant
> values. The one bugging me right now is
>
> public abstract class SolrClientBuilder> {
>
> protected HttpClient httpClient;
> protected ResponseParser responseParser;
> protected Integer connectionTimeoutMillis = 15000;
> protected Integer socketTimeoutMillis = 12;
>
> Which I am unable to change because of this code in SolrStream:
>
> /**
> * Opens the stream to a single Solr instance.
> **/
> public void open() throws IOException {
> if(cache == null) {
> client = new HttpSolrClient.Builder(baseUrl).build();
> } else {
> client = cache.getHttpSolrClient(baseUrl);
> }
>
> I need to make this particular case configurable, so that I can get results
> from a very long running query, but I sense that there is a much wider
> problem in that we don't seem to have any organized plan for how socket
> timeouts are set/managed in the code.
>
> What thoughts have people had on this front?
>
> -Gus
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8793) Enhanced UI for CustomAnalyzer : show analysis steps
[
https://issues.apache.org/jira/browse/LUCENE-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Ohtani updated LUCENE-8793:
---
Attachment: LUCENE-8793.patch
> Enhanced UI for CustomAnalyzer : show analysis steps
>
>
> Key: LUCENE-8793
> URL: https://issues.apache.org/jira/browse/LUCENE-8793
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/luke
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: LUCENE-8793.patch, Screen Shot 2019-05-06 at 10.00.57.png
>
>
> This is a migrated issue from previous Luke project in GitHub:
> [https://github.com/DmitryKey/luke/issues/134]
>
> For on-the-fly inspection / debugging, it is desirable to show the more
> detailed step by step information in the Custom Analyzer UI.
> This will be just like Solr's Analysis screen,
> [https://lucene.apache.org/solr/guide/7_5/analysis-screen.html]
> or Elasticsearch's {{_analyze}} API and Kibana's Analyzer UI.
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html]
> [https://github.com/johtani/analyze-api-ui-plugin]
--
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-8793) Enhanced UI for CustomAnalyzer : show analysis steps
[
https://issues.apache.org/jira/browse/LUCENE-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Ohtani updated LUCENE-8793:
---
Attachment: Screen Shot 2019-05-06 at 10.00.57.png
> Enhanced UI for CustomAnalyzer : show analysis steps
>
>
> Key: LUCENE-8793
> URL: https://issues.apache.org/jira/browse/LUCENE-8793
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/luke
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: Screen Shot 2019-05-06 at 10.00.57.png
>
>
> This is a migrated issue from previous Luke project in GitHub:
> [https://github.com/DmitryKey/luke/issues/134]
>
> For on-the-fly inspection / debugging, it is desirable to show the more
> detailed step by step information in the Custom Analyzer UI.
> This will be just like Solr's Analysis screen,
> [https://lucene.apache.org/solr/guide/7_5/analysis-screen.html]
> or Elasticsearch's {{_analyze}} API and Kibana's Analyzer UI.
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html]
> [https://github.com/johtani/analyze-api-ui-plugin]
--
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-13320) add a param ignoreVersionConflicts=true to updates to not overwrite existing docs
[
https://issues.apache.org/jira/browse/SOLR-13320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13320:
--
Attachment: SOLR-13320.patch
> add a param ignoreVersionConflicts=true to updates to not overwrite existing
> docs
> -
>
> Key: SOLR-13320
> URL: https://issues.apache.org/jira/browse/SOLR-13320
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-13320.patch, SOLR-13320.patch, SOLR-13320.patch
>
>
> Updates should have an option to ignore duplicate documents and drop them if
> an option {{ignoreDuplicates=true}} is specified
--
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-8793) Enhanced UI for CustomAnalyzer : show analysis steps
Jun Ohtani created LUCENE-8793:
--
Summary: Enhanced UI for CustomAnalyzer : show analysis steps
Key: LUCENE-8793
URL: https://issues.apache.org/jira/browse/LUCENE-8793
Project: Lucene - Core
Issue Type: Improvement
Components: modules/luke
Reporter: Jun Ohtani
This is a migrated issue from previous Luke project in GitHub:
[https://github.com/DmitryKey/luke/issues/134]
For on-the-fly inspection / debugging, it is desirable to show the more
detailed step by step information in the Custom Analyzer UI.
This will be just like Solr's Analysis screen,
[https://lucene.apache.org/solr/guide/7_5/analysis-screen.html]
or Elasticsearch's {{_analyze}} API and Kibana's Analyzer UI.
[https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html]
[https://github.com/johtani/analyze-api-ui-plugin]
--
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
Re: Call for help: moving from ant build to gradle
We can indeed make them work side by side. - Mark On Sun, May 5, 2019 at 11:36 AM Erick Erickson wrote: > I don’t know enough about the differences to even think consider > complaining. > > Is the proposal that we use Gradle for master and continue to use ant for > 8x? As long as the two build systems can exist side by side (i.e. we can > build master by executing some Gradle target and continue to build 8x with > Ant like we always have) the minor inconvenience doesn’t merit standing in > the way of progress. > > If that’s the case I don’t particularly care if we continue to use Ant > with 8x forever. Or maybe some ambitious person can work on bringing 8x to > Gradle after it has some mileage on master. > > And I have great faith that you wouldn’t be putting in the work unless you > thought it was worth it ;) > > Erick > > > On May 4, 2019, at 10:31 PM, Mark Miller wrote: > > > > We already dump out to groovy to do anything interesting, so I doubt > there is much we can't replicate. > > > > - Mark > > > > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > > Would beasting of tests be possible through gradle? > > > > On Sun, May 5, 2019 at 7:33 AM Mark Miller > wrote: > > > > > > I looked into this a little more. > > > > > > Seems if we just do it with master and going forward, we don’t need > multi version support - Uwe seems to have taken it out with the move to > Java 11? > > > > > > I can handle regenerate. > > > > > > The other quality checks shouldn’t be crazy. > > > > > > So I guess we can probably do this, but before I focus on BS details, > please speak up if you hate the idea of Gradle and you have the clout to > stop it. > > > > > > > > > Mark > > > > > > > > > > > > > > > On Sat, May 4, 2019 at 5:56 PM Mark Miller > wrote: > > >> > > >> I've got my own lucene-solr gradle branch as well. > > >> > > >> I stole the BuildPlugin and CheckWorkingCopy from Dat's branch, but > also made some changes. > > >> > > >> * Similar to above above, I don't move the src files so it can keep > things up to date without lots of pain. > > >> * I used a plugin that lets us define versions in a root props file > like we currently do and ensures we use the same versions in all modules > even after auto conflict resolution (unlike gradle by default) > > >> * It also locks versions so we can continue to pay attention to scary > automatic dependency resolution changes > > >> * implementation and api used instead of compile > > >> * Things build and the majority of tests pass (Lucene's > TestVirtualMethod does not for example) > > >> > > >> If someone like Uwe is serious about helping out with fun extras > (regenerating sources, extracting data from ICU, quality checks, > documentation (XSLT)), I'd look at contributing. > > >> > > >> - Mark > > >> > > >> > > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh > wrote: > > >>> > > >>> Cool Diego, > > >>> > > >>> I will take a look on this. Thanks a lot! > > >> > > >> > > >> > > >> -- > > >> - Mark > > >> > > >> http://about.me/markrmiller > > > > > > -- > > > - Mark > > > > > > http://about.me/markrmiller > > > > > > -- > > - Mark > > > > http://about.me/markrmiller > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- - Mark http://about.me/markrmiller
[JENKINS] Lucene-Solr-8.1-Linux (64bit/jdk-12) - Build # 288 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Linux/288/ Java: 64bit/jdk-12 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.HttpPartitionTest.test Error Message: Error from server at http://127.0.0.1:44185: Underlying core creation failed while creating collection: c8n_1x2 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:44185: Underlying core creation failed while creating collection: c8n_1x2 at __randomizedtesting.SeedInfo.seed([28355536098E14B6:A0616AECA772794E]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1274) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1792) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1813) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1730) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollectionRetry(AbstractFullDistribZkTestBase.java:2042) at org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:214) at org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:135) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at
[GitHub] [lucene-solr] msokolov commented on issue #657: LUCENE-8781: FST direct arc addressing
msokolov commented on issue #657: LUCENE-8781: FST direct arc addressing URL: https://github.com/apache/lucene-solr/pull/657#issuecomment-489466752 Thanks Dawid; while adding the CHANGES entry, I realized that the patch was not in fact enabling the new encoding for suggesters! Somehow I had flipped the bit while testing/submitting patches. So I re-enabled that as well, and it is still enabled for postings. 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13320) add a param ignoreVersionConflicts=true to updates to not overwrite existing docs
[
https://issues.apache.org/jira/browse/SOLR-13320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833464#comment-16833464
]
Noble Paul commented on SOLR-13320:
---
yeah, the name can be misleading. even {{continueOnversionConflict}} suggests
that you are continuing the operation irrespective of version conflict.
Continue what? continuing to add the doc ?
basically we are just ignoring only those docs with version conflicts.
basically, {{failOnVersionConflicts=false}} may be a better name?
> add a param ignoreVersionConflicts=true to updates to not overwrite existing
> docs
> -
>
> Key: SOLR-13320
> URL: https://issues.apache.org/jira/browse/SOLR-13320
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-13320.patch, SOLR-13320.patch
>
>
> Updates should have an option to ignore duplicate documents and drop them if
> an option {{ignoreDuplicates=true}} is specified
--
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
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1841 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1841/
All tests passed
Build Log:
[...truncated 63041 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj2133797719
[ecj-lint] Compiling 69 source files to /tmp/ecj2133797719
[ecj-lint] invalid Class-Path header in manifest of jar file:
/x1/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/x1/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 28)
[ecj-lint] import javax.naming.InitialContext;
[ecj-lint]^^^
[ecj-lint] The type javax.naming.InitialContext is not accessible
[ecj-lint] --
[ecj-lint] 2. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 29)
[ecj-lint] import javax.naming.NamingException;
[ecj-lint]
[ecj-lint] The type javax.naming.NamingException is not accessible
[ecj-lint] --
[ecj-lint] 3. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 182)
[ecj-lint] c = getFromJndi(initProps, jndiName);
[ecj-lint] ^^^
[ecj-lint] The method getFromJndi(Properties, String) from the type new
Callable(){} refers to the missing type NamingException
[ecj-lint] --
[ecj-lint] 4. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 245)
[ecj-lint] private Connection getFromJndi(final Properties initProps,
final String jndiName) throws NamingException,
[ecj-lint]
^^^
[ecj-lint] NamingException cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 5. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 249)
[ecj-lint] InitialContext ctx = new InitialContext();
[ecj-lint] ^^
[ecj-lint] InitialContext cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 6. ERROR in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 249)
[ecj-lint] InitialContext ctx = new InitialContext();
[ecj-lint] ^^
[ecj-lint] InitialContext cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 6 problems (6 errors)
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/build.xml:652:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/build.xml:101:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/build.xml:687:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/common-build.xml:479:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/lucene/common-build.xml:2010:
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/lucene/common-build.xml:2049:
Compile failed; see the compiler error output for details.
Total time: 334 minutes 25 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13320) add a param ignoreVersionConflicts=true to updates to not overwrite existing docs
[
https://issues.apache.org/jira/browse/SOLR-13320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833460#comment-16833460
]
Yonik Seeley commented on SOLR-13320:
-
Hmmm, when I read "ignoreVersionConflicts" I assumed the wrong behavior... go
ahead and add even if there is a version conflict. We aren't really ignoring
it, but rather continuing on to the next update/doc in the batch after it
happened?
I'm not sure if I can think if a better name though... thinking along the lines
of [~gus_heck],
maybe something like "continueOnVersionConflict" (or "continueOnError" for the
general case)?
> add a param ignoreVersionConflicts=true to updates to not overwrite existing
> docs
> -
>
> Key: SOLR-13320
> URL: https://issues.apache.org/jira/browse/SOLR-13320
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-13320.patch, SOLR-13320.patch
>
>
> Updates should have an option to ignore duplicate documents and drop them if
> an option {{ignoreDuplicates=true}} is specified
--
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
Re: Call for help: moving from ant build to gradle
I'm not particularly moved by any performance differences. And the gradle daemon is not my friend. I see the main benefits of gradle as: Our current ant+ivy+maven system is an insanely complicated Frankenstein. It's high barrier of entry for new devs and does our project a disservice. Adding or changing things is painful. The maven shadow build is painful. Switching to gradle means deleting tons of crap - all sorts of work arounds and ant abuse go away. gradle can be configured to do auto version resolution in a sensable way for us - when done right, this is a large improvement over devs resolving version conflicts on their own, ad hoc. - Mark On Sun, May 5, 2019 at 2:13 PM Dawid Weiss wrote: > Sure, maybe. My feelings towards Gradle range from love to fury (and > quite frequently in short time spans). For example I'm sort of > wondering what will happen to those build machines (which aren't > exactly speed beasts) when you launch multiple builds on different > JVMs; gradle is fast once it has an up-to-date daemon... but leaving > stray processes behind on a CI machine is going to hurt sooner or > later. > > Don't get me wrong -- I like gradle, really. But I've had enough "wtf" > moments with it not to be too excited either. :) > > Dawid > > On Sun, May 5, 2019 at 8:50 PM Varun Thacker wrote: > > > > I think you're right on the tests part. > > > > Task that are run by the QA Bot ( > https://issues.apache.org/jira/browse/SOLR-13049?focusedCommentId=16832997=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16832997 > ) could benefit from caching though right? > > > > On Sun, May 5, 2019 at 11:39 AM Dawid Weiss > wrote: > >> > >> I think most of the build time is spent in tests. Since we're using > >> randomization I don't think you'd gain much from caches? > >> > >> Dawid > >> > >> On Sun, May 5, 2019 at 8:24 PM Varun Thacker wrote: > >> > > >> > Over the last few months, I've realized the power of build caches. > >> > > >> > In the future could we have remote caches for Jenkins? In which case > the Lucene/Solr QA bot will be significantly faster as well? And then it > could just run against all patches and even block commits that violate it? > >> > > >> > On Sun, May 5, 2019 at 9:37 AM Erick Erickson < > erickerick...@gmail.com> wrote: > >> >> > >> >> I don’t know enough about the differences to even think consider > complaining. > >> >> > >> >> Is the proposal that we use Gradle for master and continue to use > ant for 8x? As long as the two build systems can exist side by side (i.e. > we can build master by executing some Gradle target and continue to build > 8x with Ant like we always have) the minor inconvenience doesn’t merit > standing in the way of progress. > >> >> > >> >> If that’s the case I don’t particularly care if we continue to use > Ant with 8x forever. Or maybe some ambitious person can work on bringing 8x > to Gradle after it has some mileage on master. > >> >> > >> >> And I have great faith that you wouldn’t be putting in the work > unless you thought it was worth it ;) > >> >> > >> >> Erick > >> >> > >> >> > On May 4, 2019, at 10:31 PM, Mark Miller > wrote: > >> >> > > >> >> > We already dump out to groovy to do anything interesting, so I > doubt there is much we can't replicate. > >> >> > > >> >> > - Mark > >> >> > > >> >> > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> >> > Would beasting of tests be possible through gradle? > >> >> > > >> >> > On Sun, May 5, 2019 at 7:33 AM Mark Miller > wrote: > >> >> > > > >> >> > > I looked into this a little more. > >> >> > > > >> >> > > Seems if we just do it with master and going forward, we don’t > need multi version support - Uwe seems to have taken it out with the move > to Java 11? > >> >> > > > >> >> > > I can handle regenerate. > >> >> > > > >> >> > > The other quality checks shouldn’t be crazy. > >> >> > > > >> >> > > So I guess we can probably do this, but before I focus on BS > details, please speak up if you hate the idea of Gradle and you have the > clout to stop it. > >> >> > > > >> >> > > > >> >> > > Mark > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller < > markrmil...@gmail.com> wrote: > >> >> > >> > >> >> > >> I've got my own lucene-solr gradle branch as well. > >> >> > >> > >> >> > >> I stole the BuildPlugin and CheckWorkingCopy from Dat's branch, > but also made some changes. > >> >> > >> > >> >> > >> * Similar to above above, I don't move the src files so it can > keep things up to date without lots of pain. > >> >> > >> * I used a plugin that lets us define versions in a root props > file like we currently do and ensures we use the same versions in all > modules even after auto conflict resolution (unlike gradle by default) > >> >> > >> * It also locks versions so we can continue to pay attention to > scary automatic dependency resolution changes > >> >> > >> * implementation and api
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+18) - Build # 24039 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24039/ Java: 64bit/jdk-13-ea+18 -XX:-UseCompressedOops -XX:+UseSerialGC 8 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest Error Message: SOLR-11606: ByteBuddy used by Mockito is not working with this JVM version. Stack Trace: org.junit.AssumptionViolatedException: SOLR-11606: ByteBuddy used by Mockito is not working with this JVM version. at __randomizedtesting.SeedInfo.seed([1D0B51D25A09A231]:0) at com.carrotsearch.randomizedtesting.RandomizedTest.assumeNoException(RandomizedTest.java:742) at org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:374) at org.apache.solr.update.processor.DistributedUpdateProcessorTest.beforeClass(DistributedUpdateProcessorTest.java:60) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:878) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:835) Caused by: java.lang.IllegalArgumentException: Unknown Java version: 13 at net.bytebuddy.ClassFileVersion.ofJavaVersion(ClassFileVersion.java:210) at net.bytebuddy.ClassFileVersion$VersionLocator$ForJava9CapableVm.locate(ClassFileVersion.java:462) at net.bytebuddy.ClassFileVersion.ofThisVm(ClassFileVersion.java:223) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:372) ... 24 more FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([1D0B51D25A09A231]:0) at org.apache.solr.update.processor.DistributedUpdateProcessorTest.AfterClass(DistributedUpdateProcessorTest.java:67) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at
[jira] [Commented] (SOLR-12562) Remove redundant RealTimeGetCompnent.toSolrDoc and use DocStreamer.convertLuceneDocToSolrDoc
[
https://issues.apache.org/jira/browse/SOLR-12562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833438#comment-16833438
]
David Smiley commented on SOLR-12562:
-
Can you see if we can remove {{materialize()}} altogether by always using the
logic {{schemaField.getType().toObject(indexableField)}}?
If we retain the two methods specified in the issue title, I think we should
add a comment in both places referring to each other to acknowledge the similar
code. It'll help us maintain this in the future.
> Remove redundant RealTimeGetCompnent.toSolrDoc and use
> DocStreamer.convertLuceneDocToSolrDoc
>
>
> Key: SOLR-12562
> URL: https://issues.apache.org/jira/browse/SOLR-12562
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-12562.patch
>
>
> This code looks really redundant so we should remove one. The one in
> RealTimeGet is the only used locally so my vote is to remove that one.
--
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
Re: Call for help: moving from ant build to gradle
Sure, maybe. My feelings towards Gradle range from love to fury (and quite frequently in short time spans). For example I'm sort of wondering what will happen to those build machines (which aren't exactly speed beasts) when you launch multiple builds on different JVMs; gradle is fast once it has an up-to-date daemon... but leaving stray processes behind on a CI machine is going to hurt sooner or later. Don't get me wrong -- I like gradle, really. But I've had enough "wtf" moments with it not to be too excited either. :) Dawid On Sun, May 5, 2019 at 8:50 PM Varun Thacker wrote: > > I think you're right on the tests part. > > Task that are run by the QA Bot ( > https://issues.apache.org/jira/browse/SOLR-13049?focusedCommentId=16832997=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16832997 > ) could benefit from caching though right? > > On Sun, May 5, 2019 at 11:39 AM Dawid Weiss wrote: >> >> I think most of the build time is spent in tests. Since we're using >> randomization I don't think you'd gain much from caches? >> >> Dawid >> >> On Sun, May 5, 2019 at 8:24 PM Varun Thacker wrote: >> > >> > Over the last few months, I've realized the power of build caches. >> > >> > In the future could we have remote caches for Jenkins? In which case the >> > Lucene/Solr QA bot will be significantly faster as well? And then it could >> > just run against all patches and even block commits that violate it? >> > >> > On Sun, May 5, 2019 at 9:37 AM Erick Erickson >> > wrote: >> >> >> >> I don’t know enough about the differences to even think consider >> >> complaining. >> >> >> >> Is the proposal that we use Gradle for master and continue to use ant for >> >> 8x? As long as the two build systems can exist side by side (i.e. we can >> >> build master by executing some Gradle target and continue to build 8x >> >> with Ant like we always have) the minor inconvenience doesn’t merit >> >> standing in the way of progress. >> >> >> >> If that’s the case I don’t particularly care if we continue to use Ant >> >> with 8x forever. Or maybe some ambitious person can work on bringing 8x >> >> to Gradle after it has some mileage on master. >> >> >> >> And I have great faith that you wouldn’t be putting in the work unless >> >> you thought it was worth it ;) >> >> >> >> Erick >> >> >> >> > On May 4, 2019, at 10:31 PM, Mark Miller wrote: >> >> > >> >> > We already dump out to groovy to do anything interesting, so I doubt >> >> > there is much we can't replicate. >> >> > >> >> > - Mark >> >> > >> >> > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya >> >> > wrote: >> >> > Would beasting of tests be possible through gradle? >> >> > >> >> > On Sun, May 5, 2019 at 7:33 AM Mark Miller >> >> > wrote: >> >> > > >> >> > > I looked into this a little more. >> >> > > >> >> > > Seems if we just do it with master and going forward, we don’t need >> >> > > multi version support - Uwe seems to have taken it out with the move >> >> > > to Java 11? >> >> > > >> >> > > I can handle regenerate. >> >> > > >> >> > > The other quality checks shouldn’t be crazy. >> >> > > >> >> > > So I guess we can probably do this, but before I focus on BS details, >> >> > > please speak up if you hate the idea of Gradle and you have the clout >> >> > > to stop it. >> >> > > >> >> > > >> >> > > Mark >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller >> >> > > wrote: >> >> > >> >> >> > >> I've got my own lucene-solr gradle branch as well. >> >> > >> >> >> > >> I stole the BuildPlugin and CheckWorkingCopy from Dat's branch, but >> >> > >> also made some changes. >> >> > >> >> >> > >> * Similar to above above, I don't move the src files so it can keep >> >> > >> things up to date without lots of pain. >> >> > >> * I used a plugin that lets us define versions in a root props file >> >> > >> like we currently do and ensures we use the same versions in all >> >> > >> modules even after auto conflict resolution (unlike gradle by >> >> > >> default) >> >> > >> * It also locks versions so we can continue to pay attention to >> >> > >> scary automatic dependency resolution changes >> >> > >> * implementation and api used instead of compile >> >> > >> * Things build and the majority of tests pass (Lucene's >> >> > >> TestVirtualMethod does not for example) >> >> > >> >> >> > >> If someone like Uwe is serious about helping out with fun extras >> >> > >> (regenerating sources, extracting data from ICU, quality checks, >> >> > >> documentation (XSLT)), I'd look at contributing. >> >> > >> >> >> > >> - Mark >> >> > >> >> >> > >> >> >> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh >> >> > >> wrote: >> >> > >>> >> >> > >>> Cool Diego, >> >> > >>> >> >> > >>> I will take a look on this. Thanks a lot! >> >> > >> >> >> > >> >> >> > >> >> >> > >> -- >> >> > >> - Mark >> >> > >> >> >> > >> http://about.me/markrmiller >> >> > > >> >> > > -- >> >> > > - Mark >> >> > > >> >> > >
Re: Socket Timeouts
@Martin, yeah I expected that to work initially, but it has no effect on
the streaming expression code path.
@Kevin, thx for the link :)
On Sun, May 5, 2019, 2:49 PM Martin Gainty wrote:
> both connectionTimeout and socketTimeout are declared in
> $SOLR_HOME/solr.xml
>
> class="HttpShardHandlerFactory">
> ${socketTimeout:60}
> ${connTimeout:6}
>
>
>
>
>
> --
> *From:* Gus Heck
> *Sent:* Sunday, May 5, 2019 1:35 PM
> *To:* dev
> *Subject:* Socket Timeouts
>
> I'm working with a client that's trying to process a lot of data (billions
> of docs) via a streaming expression, and the initial query is (not
> surprisingly) taking a long time. Lots of various types of timeouts have
> been cropping up and I've found myself thinking I solved some only to
> discover that the settings in solr.xml are far less wide reaching than I
> thought initially. The present 5% scale cluster seems to hit one particular
> time out about 50% of the time which has made it particularly confusing.
> I'm guessing it's probably depending on something like how busy the
> virtualization in Amazon is, just barely making it when it gets more
> resources and timing out if anything is starved.
>
> As I look around the code base I'm finding a LOT of places where timeouts
> on SolrClients and CloudSolrClients are just arbitrarily set to one-off
> constant values. The one bugging me right now is
>
> public abstract class SolrClientBuilder> {
>
> protected HttpClient httpClient;
> protected ResponseParser responseParser;
> protected Integer connectionTimeoutMillis = 15000;
> protected Integer socketTimeoutMillis = 12;
>
> Which I am unable to change because of this code in SolrStream:
>
> /**
> * Opens the stream to a single Solr instance.
> **/
> public void open() throws IOException {
> if(cache == null) {
> client = new HttpSolrClient.Builder(baseUrl).build();
> } else {
> client = cache.getHttpSolrClient(baseUrl);
> }
>
> I need to make this particular case configurable, so that I can get
> results from a very long running query, but I sense that there is a much
> wider problem in that we don't seem to have any organized plan for how
> socket timeouts are set/managed in the code.
>
> What thoughts have people had on this front?
>
> -Gus
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
[jira] [Commented] (SOLR-13263) Facet Heat Map should support GeoJSON
[
https://issues.apache.org/jira/browse/SOLR-13263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833433#comment-16833433
]
David Smiley commented on SOLR-13263:
-
bq. SpatialHeatmapFacetsTest#testGeoJsonBounds -> This test shows the odd
behavior showcased by Geo3D parsing context. When a Polygon is parsed in
GeoJson form, its bounding box seems to default to GeoWorld, as can be seen in
SpatialHeatmapFacetsTest#testGeoJsonBounds:341.
Indeed something seems wrong here. I played with that in a debugger and it's a
bit over my head but _appears_ to be a deficiency in Geo3D's
{{GeoConcavePolygon.getBounds}} CC [~daddywri] (see above).
The testGeoJsonBounds method also has several problems:
* On the surface of a sphere, the parsed shape of 4 points is different than a
Euclidean 2D plane. Geo3D is surface-of-sphere. Thus horizontal lines above
the equator bow upwards when viewed on a 2D plane. So the test is
fundamentally wrong to compare a surface-of-sphere shape to a lat-lon rectangle
(which isn't surface-of-sphere) wherein the inputs are the same since the
result won't match.
* Your top latitude is 90 which touches the north pole. _Debatably_ this wraps
the world; you could argue it either way. This makes reasoning about what the
bounding box _should_ be in a test debatable and thus not a good test input.
You could lower to say 70.
* Something trivial: confusingly, you pass an "expected" named var to the
second param of assertEquals when as that method documents, it should be the
first.
bq. SpatialHeatmapFacetsTest#testGeoJsonFacets
I don't notice any parsing bug. Keep in mind the first few things the test
asserts are that it fails for distErr=0 and distErrPct=0 so you might be
looking at expected failures, though we ignore them.
*org.apache.solr.util.SpatialUtils#parseGeomSolrException*
This seems to be the deficiency you identified that needs to be enhanced -- the
key to this issue and maybe others. I'm not sure I like looking for the
substring " TO " since perhaps it might be found in some spatial input. A
compiled regular expression would be safer. Perhaps we should use one
compatible with what Solr's parser does in
{{org/apache/solr/parser/QueryParser.jj}}.
> Facet Heat Map should support GeoJSON
> -
>
> Key: SOLR-13263
> URL: https://issues.apache.org/jira/browse/SOLR-13263
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, faceting
>Affects Versions: 8.0, 8.1, master (9.0)
>Reporter: Bar Rotstein
>Priority: Major
> Labels: Facets, Geolocation, facet, faceting, geo
> Attachments: SOLR-13263-nocommit-geo3d-failure.patch,
> SOLR-13263-nocommit.patch
>
>
> Currently Facet Heatmap(Geographical facets) do not support any other
> subjects other than WKT or '[ ]'. This seems to be caused since
> FacetHeatmap.Parser#parse uses SpatialUtils#parseGeomSolrException, which in
> turn uses a deprecated JTS method (SpatialContext#readShapeFromWkt) to parse
> the string input.
> The newer method of parsing a String to a Shape object should be used, makes
> the code a lot cleaner and should support more formats (including GeoJSON).
--
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
Re: Call for help: moving from ant build to gradle
I think you're right on the tests part. Task that are run by the QA Bot ( https://issues.apache.org/jira/browse/SOLR-13049?focusedCommentId=16832997=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16832997 ) could benefit from caching though right? On Sun, May 5, 2019 at 11:39 AM Dawid Weiss wrote: > I think most of the build time is spent in tests. Since we're using > randomization I don't think you'd gain much from caches? > > Dawid > > On Sun, May 5, 2019 at 8:24 PM Varun Thacker wrote: > > > > Over the last few months, I've realized the power of build caches. > > > > In the future could we have remote caches for Jenkins? In which case the > Lucene/Solr QA bot will be significantly faster as well? And then it could > just run against all patches and even block commits that violate it? > > > > On Sun, May 5, 2019 at 9:37 AM Erick Erickson > wrote: > >> > >> I don’t know enough about the differences to even think consider > complaining. > >> > >> Is the proposal that we use Gradle for master and continue to use ant > for 8x? As long as the two build systems can exist side by side (i.e. we > can build master by executing some Gradle target and continue to build 8x > with Ant like we always have) the minor inconvenience doesn’t merit > standing in the way of progress. > >> > >> If that’s the case I don’t particularly care if we continue to use Ant > with 8x forever. Or maybe some ambitious person can work on bringing 8x to > Gradle after it has some mileage on master. > >> > >> And I have great faith that you wouldn’t be putting in the work unless > you thought it was worth it ;) > >> > >> Erick > >> > >> > On May 4, 2019, at 10:31 PM, Mark Miller > wrote: > >> > > >> > We already dump out to groovy to do anything interesting, so I doubt > there is much we can't replicate. > >> > > >> > - Mark > >> > > >> > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> > Would beasting of tests be possible through gradle? > >> > > >> > On Sun, May 5, 2019 at 7:33 AM Mark Miller > wrote: > >> > > > >> > > I looked into this a little more. > >> > > > >> > > Seems if we just do it with master and going forward, we don’t need > multi version support - Uwe seems to have taken it out with the move to > Java 11? > >> > > > >> > > I can handle regenerate. > >> > > > >> > > The other quality checks shouldn’t be crazy. > >> > > > >> > > So I guess we can probably do this, but before I focus on BS > details, please speak up if you hate the idea of Gradle and you have the > clout to stop it. > >> > > > >> > > > >> > > Mark > >> > > > >> > > > >> > > > >> > > > >> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller > wrote: > >> > >> > >> > >> I've got my own lucene-solr gradle branch as well. > >> > >> > >> > >> I stole the BuildPlugin and CheckWorkingCopy from Dat's branch, > but also made some changes. > >> > >> > >> > >> * Similar to above above, I don't move the src files so it can > keep things up to date without lots of pain. > >> > >> * I used a plugin that lets us define versions in a root props > file like we currently do and ensures we use the same versions in all > modules even after auto conflict resolution (unlike gradle by default) > >> > >> * It also locks versions so we can continue to pay attention to > scary automatic dependency resolution changes > >> > >> * implementation and api used instead of compile > >> > >> * Things build and the majority of tests pass (Lucene's > TestVirtualMethod does not for example) > >> > >> > >> > >> If someone like Uwe is serious about helping out with fun extras > (regenerating sources, extracting data from ICU, quality checks, > documentation (XSLT)), I'd look at contributing. > >> > >> > >> > >> - Mark > >> > >> > >> > >> > >> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh < > caomanhdat...@gmail.com> wrote: > >> > >>> > >> > >>> Cool Diego, > >> > >>> > >> > >>> I will take a look on this. Thanks a lot! > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> - Mark > >> > >> > >> > >> http://about.me/markrmiller > >> > > > >> > > -- > >> > > - Mark > >> > > > >> > > http://about.me/markrmiller > >> > > >> > > >> > -- > >> > - Mark > >> > > >> > http://about.me/markrmiller > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Socket Timeouts
both connectionTimeout and socketTimeout are declared in $SOLR_HOME/solr.xml
${socketTimeout:60}
${connTimeout:6}
From: Gus Heck
Sent: Sunday, May 5, 2019 1:35 PM
To: dev
Subject: Socket Timeouts
I'm working with a client that's trying to process a lot of data (billions of
docs) via a streaming expression, and the initial query is (not surprisingly)
taking a long time. Lots of various types of timeouts have been cropping up and
I've found myself thinking I solved some only to discover that the settings in
solr.xml are far less wide reaching than I thought initially. The present 5%
scale cluster seems to hit one particular time out about 50% of the time which
has made it particularly confusing. I'm guessing it's probably depending on
something like how busy the virtualization in Amazon is, just barely making it
when it gets more resources and timing out if anything is starved.
As I look around the code base I'm finding a LOT of places where timeouts on
SolrClients and CloudSolrClients are just arbitrarily set to one-off constant
values. The one bugging me right now is
public abstract class SolrClientBuilder> {
protected HttpClient httpClient;
protected ResponseParser responseParser;
protected Integer connectionTimeoutMillis = 15000;
protected Integer socketTimeoutMillis = 12;
Which I am unable to change because of this code in SolrStream:
/**
* Opens the stream to a single Solr instance.
**/
public void open() throws IOException {
if(cache == null) {
client = new HttpSolrClient.Builder(baseUrl).build();
} else {
client = cache.getHttpSolrClient(baseUrl);
}
I need to make this particular case configurable, so that I can get results
from a very long running query, but I sense that there is a much wider problem
in that we don't seem to have any organized plan for how socket timeouts are
set/managed in the code.
What thoughts have people had on this front?
-Gus
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Call for help: moving from ant build to gradle
I think most of the build time is spent in tests. Since we're using randomization I don't think you'd gain much from caches? Dawid On Sun, May 5, 2019 at 8:24 PM Varun Thacker wrote: > > Over the last few months, I've realized the power of build caches. > > In the future could we have remote caches for Jenkins? In which case the > Lucene/Solr QA bot will be significantly faster as well? And then it could > just run against all patches and even block commits that violate it? > > On Sun, May 5, 2019 at 9:37 AM Erick Erickson wrote: >> >> I don’t know enough about the differences to even think consider complaining. >> >> Is the proposal that we use Gradle for master and continue to use ant for >> 8x? As long as the two build systems can exist side by side (i.e. we can >> build master by executing some Gradle target and continue to build 8x with >> Ant like we always have) the minor inconvenience doesn’t merit standing in >> the way of progress. >> >> If that’s the case I don’t particularly care if we continue to use Ant with >> 8x forever. Or maybe some ambitious person can work on bringing 8x to Gradle >> after it has some mileage on master. >> >> And I have great faith that you wouldn’t be putting in the work unless you >> thought it was worth it ;) >> >> Erick >> >> > On May 4, 2019, at 10:31 PM, Mark Miller wrote: >> > >> > We already dump out to groovy to do anything interesting, so I doubt there >> > is much we can't replicate. >> > >> > - Mark >> > >> > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya >> > wrote: >> > Would beasting of tests be possible through gradle? >> > >> > On Sun, May 5, 2019 at 7:33 AM Mark Miller wrote: >> > > >> > > I looked into this a little more. >> > > >> > > Seems if we just do it with master and going forward, we don’t need >> > > multi version support - Uwe seems to have taken it out with the move to >> > > Java 11? >> > > >> > > I can handle regenerate. >> > > >> > > The other quality checks shouldn’t be crazy. >> > > >> > > So I guess we can probably do this, but before I focus on BS details, >> > > please speak up if you hate the idea of Gradle and you have the clout to >> > > stop it. >> > > >> > > >> > > Mark >> > > >> > > >> > > >> > > >> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller wrote: >> > >> >> > >> I've got my own lucene-solr gradle branch as well. >> > >> >> > >> I stole the BuildPlugin and CheckWorkingCopy from Dat's branch, but >> > >> also made some changes. >> > >> >> > >> * Similar to above above, I don't move the src files so it can keep >> > >> things up to date without lots of pain. >> > >> * I used a plugin that lets us define versions in a root props file >> > >> like we currently do and ensures we use the same versions in all >> > >> modules even after auto conflict resolution (unlike gradle by default) >> > >> * It also locks versions so we can continue to pay attention to scary >> > >> automatic dependency resolution changes >> > >> * implementation and api used instead of compile >> > >> * Things build and the majority of tests pass (Lucene's >> > >> TestVirtualMethod does not for example) >> > >> >> > >> If someone like Uwe is serious about helping out with fun extras >> > >> (regenerating sources, extracting data from ICU, quality checks, >> > >> documentation (XSLT)), I'd look at contributing. >> > >> >> > >> - Mark >> > >> >> > >> >> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh >> > >> wrote: >> > >>> >> > >>> Cool Diego, >> > >>> >> > >>> I will take a look on this. Thanks a lot! >> > >> >> > >> >> > >> >> > >> -- >> > >> - Mark >> > >> >> > >> http://about.me/markrmiller >> > > >> > > -- >> > > - Mark >> > > >> > > http://about.me/markrmiller >> > >> > >> > -- >> > - Mark >> > >> > http://about.me/markrmiller >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Socket Timeouts
You might be interested in:
https://issues.apache.org/jira/browse/SOLR-13389
Kevin Risden
On Sun, May 5, 2019 at 1:35 PM Gus Heck wrote:
> I'm working with a client that's trying to process a lot of data (billions
> of docs) via a streaming expression, and the initial query is (not
> surprisingly) taking a long time. Lots of various types of timeouts have
> been cropping up and I've found myself thinking I solved some only to
> discover that the settings in solr.xml are far less wide reaching than I
> thought initially. The present 5% scale cluster seems to hit one particular
> time out about 50% of the time which has made it particularly confusing.
> I'm guessing it's probably depending on something like how busy the
> virtualization in Amazon is, just barely making it when it gets more
> resources and timing out if anything is starved.
>
> As I look around the code base I'm finding a LOT of places where timeouts
> on SolrClients and CloudSolrClients are just arbitrarily set to one-off
> constant values. The one bugging me right now is
>
> public abstract class SolrClientBuilder> {
>
> protected HttpClient httpClient;
> protected ResponseParser responseParser;
> protected Integer connectionTimeoutMillis = 15000;
> protected Integer socketTimeoutMillis = 12;
>
> Which I am unable to change because of this code in SolrStream:
>
> /**
> * Opens the stream to a single Solr instance.
> **/
> public void open() throws IOException {
> if(cache == null) {
> client = new HttpSolrClient.Builder(baseUrl).build();
> } else {
> client = cache.getHttpSolrClient(baseUrl);
> }
>
> I need to make this particular case configurable, so that I can get
> results from a very long running query, but I sense that there is a much
> wider problem in that we don't seem to have any organized plan for how
> socket timeouts are set/managed in the code.
>
> What thoughts have people had on this front?
>
> -Gus
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
[jira] [Commented] (SOLR-13420) Allow Routed Aliases to use Collection Properties instead of core properties
[
https://issues.apache.org/jira/browse/SOLR-13420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833428#comment-16833428
]
Gus Heck commented on SOLR-13420:
-
Have I answered your concerns? I'd like to move this forward soon.
> Allow Routed Aliases to use Collection Properties instead of core properties
>
>
> Key: SOLR-13420
> URL: https://issues.apache.org/jira/browse/SOLR-13420
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Attachments: SOLR-13420.patch, SOLR-13420.patch, SOLR-13420.patch,
> SOLR-13420.patch
>
>
> The current routed alias code is relying on a core property named
> routedAliasName to detect when the Routed Alias wrapper URP should be applied
> to Distributed Update Request Processor.
> {code:java}
> #Written by CorePropertiesLocator
> #Sun Mar 03 06:21:14 UTC 2019
> routedAliasName=testalias21
> numShards=2
> collection.configName=_default
> ... etc...
> {code}
> Core properties are not changeable after the core is created, and they are
> written to the file system for every core. To support a unit test for
> SOLR-13419 I need to create some legacy formatted collection names, and
> arrange them into a TRA, but this is impossible due to the fact that I can't
> change the core property from the test. There's a TODO dating back to the
> original TRA implementation in the routed alias code to switch to collection
> properties instead, so this ticket will address that TOD to support the test
> required for SOLR-13419.
> Back compatibility with legacy core based TRA's and CRA's will of course be
> maintained. I also expect that this will facilitate some more nimble handling
> or routed aliases with future auto-scaling capabilities such as possibly
> detaching and archiving collections to cheaper, slower machines rather than
> deleting them. (presently such a collection would still attempt to use the
> routed alias if it received an update even if it were no longer in the list
> of collections for the alias)
--
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
Re: Call for help: moving from ant build to gradle
Over the last few months, I've realized the power of build caches. In the future could we have remote caches for Jenkins? In which case the Lucene/Solr QA bot will be significantly faster as well? And then it could just run against all patches and even block commits that violate it? On Sun, May 5, 2019 at 9:37 AM Erick Erickson wrote: > I don’t know enough about the differences to even think consider > complaining. > > Is the proposal that we use Gradle for master and continue to use ant for > 8x? As long as the two build systems can exist side by side (i.e. we can > build master by executing some Gradle target and continue to build 8x with > Ant like we always have) the minor inconvenience doesn’t merit standing in > the way of progress. > > If that’s the case I don’t particularly care if we continue to use Ant > with 8x forever. Or maybe some ambitious person can work on bringing 8x to > Gradle after it has some mileage on master. > > And I have great faith that you wouldn’t be putting in the work unless you > thought it was worth it ;) > > Erick > > > On May 4, 2019, at 10:31 PM, Mark Miller wrote: > > > > We already dump out to groovy to do anything interesting, so I doubt > there is much we can't replicate. > > > > - Mark > > > > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > > Would beasting of tests be possible through gradle? > > > > On Sun, May 5, 2019 at 7:33 AM Mark Miller > wrote: > > > > > > I looked into this a little more. > > > > > > Seems if we just do it with master and going forward, we don’t need > multi version support - Uwe seems to have taken it out with the move to > Java 11? > > > > > > I can handle regenerate. > > > > > > The other quality checks shouldn’t be crazy. > > > > > > So I guess we can probably do this, but before I focus on BS details, > please speak up if you hate the idea of Gradle and you have the clout to > stop it. > > > > > > > > > Mark > > > > > > > > > > > > > > > On Sat, May 4, 2019 at 5:56 PM Mark Miller > wrote: > > >> > > >> I've got my own lucene-solr gradle branch as well. > > >> > > >> I stole the BuildPlugin and CheckWorkingCopy from Dat's branch, but > also made some changes. > > >> > > >> * Similar to above above, I don't move the src files so it can keep > things up to date without lots of pain. > > >> * I used a plugin that lets us define versions in a root props file > like we currently do and ensures we use the same versions in all modules > even after auto conflict resolution (unlike gradle by default) > > >> * It also locks versions so we can continue to pay attention to scary > automatic dependency resolution changes > > >> * implementation and api used instead of compile > > >> * Things build and the majority of tests pass (Lucene's > TestVirtualMethod does not for example) > > >> > > >> If someone like Uwe is serious about helping out with fun extras > (regenerating sources, extracting data from ICU, quality checks, > documentation (XSLT)), I'd look at contributing. > > >> > > >> - Mark > > >> > > >> > > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh > wrote: > > >>> > > >>> Cool Diego, > > >>> > > >>> I will take a look on this. Thanks a lot! > > >> > > >> > > >> > > >> -- > > >> - Mark > > >> > > >> http://about.me/markrmiller > > > > > > -- > > > - Mark > > > > > > http://about.me/markrmiller > > > > > > -- > > - Mark > > > > http://about.me/markrmiller > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Updated] (SOLR-13410) Designated overseer not able to become overseer quickly
[ https://issues.apache.org/jira/browse/SOLR-13410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kesharee Nandan Vishwakarma updated SOLR-13410: --- Attachment: SOLR-13410.patch > Designated overseer not able to become overseer quickly > > > Key: SOLR-13410 > URL: https://issues.apache.org/jira/browse/SOLR-13410 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (9.0) >Reporter: Kesharee Nandan Vishwakarma >Assignee: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.1 > > Attachments: SOLR-13410.patch, SOLR-13410.patch, SOLR-13410.patch, > SOLR-13410.patch, overseerElection.log > > > Whenever a designated overseer node is restarted and overseer role is added > back if a designated node is not overseer leader following tasks take place: > 1. one by one nodes from electionNodes list become leader and ask designated > node `to come join election at head` > 2. current overseer node Fires Quit command and exits from Overseer Loop > 3. Next node from `Overseer Loop` becomes leader repeats steps 1,2 until > designated overseer node becomes the leader > Problem with above flow: OverseerNodePrioritizer is not able to add > `designated node` at the head of electionNodes list > Steps to reproduce: > # Setup solrcloud with 5 nodes, including one designated overseer > # Restart overseer container > Attached relevant logs -- 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-13410) Designated overseer not able to become overseer quickly
[ https://issues.apache.org/jira/browse/SOLR-13410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kesharee Nandan Vishwakarma updated SOLR-13410: --- Attachment: (was: SOLR-13410.patch) > Designated overseer not able to become overseer quickly > > > Key: SOLR-13410 > URL: https://issues.apache.org/jira/browse/SOLR-13410 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (9.0) >Reporter: Kesharee Nandan Vishwakarma >Assignee: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.1 > > Attachments: SOLR-13410.patch, SOLR-13410.patch, SOLR-13410.patch, > SOLR-13410.patch, overseerElection.log > > > Whenever a designated overseer node is restarted and overseer role is added > back if a designated node is not overseer leader following tasks take place: > 1. one by one nodes from electionNodes list become leader and ask designated > node `to come join election at head` > 2. current overseer node Fires Quit command and exits from Overseer Loop > 3. Next node from `Overseer Loop` becomes leader repeats steps 1,2 until > designated overseer node becomes the leader > Problem with above flow: OverseerNodePrioritizer is not able to add > `designated node` at the head of electionNodes list > Steps to reproduce: > # Setup solrcloud with 5 nodes, including one designated overseer > # Restart overseer container > Attached relevant logs -- 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-13410) Designated overseer not able to become overseer quickly
[ https://issues.apache.org/jira/browse/SOLR-13410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kesharee Nandan Vishwakarma updated SOLR-13410: --- Attachment: SOLR-13410.patch > Designated overseer not able to become overseer quickly > > > Key: SOLR-13410 > URL: https://issues.apache.org/jira/browse/SOLR-13410 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (9.0) >Reporter: Kesharee Nandan Vishwakarma >Assignee: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.1 > > Attachments: SOLR-13410.patch, SOLR-13410.patch, SOLR-13410.patch, > SOLR-13410.patch, overseerElection.log > > > Whenever a designated overseer node is restarted and overseer role is added > back if a designated node is not overseer leader following tasks take place: > 1. one by one nodes from electionNodes list become leader and ask designated > node `to come join election at head` > 2. current overseer node Fires Quit command and exits from Overseer Loop > 3. Next node from `Overseer Loop` becomes leader repeats steps 1,2 until > designated overseer node becomes the leader > Problem with above flow: OverseerNodePrioritizer is not able to add > `designated node` at the head of electionNodes list > Steps to reproduce: > # Setup solrcloud with 5 nodes, including one designated overseer > # Restart overseer container > Attached relevant logs -- 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] (SOLR-13410) Designated overseer not able to become overseer quickly
[ https://issues.apache.org/jira/browse/SOLR-13410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833426#comment-16833426 ] Kesharee Nandan Vishwakarma commented on SOLR-13410: Hi [~ichattopadhyaya], It seems two test cases in OverseerRolesTest are interfering with each other, since they are running on the same cluster. OverseerCollectionConfigSetProcessor.getLeaderNode(zkClient()) returns null at times due to that. We can include test cases for this fix in the existing test testOverseerRole. Please refer to the patch for the same. We can also try using a separate cluster for this or including huge wait time before each test can also help. > Designated overseer not able to become overseer quickly > > > Key: SOLR-13410 > URL: https://issues.apache.org/jira/browse/SOLR-13410 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (9.0) >Reporter: Kesharee Nandan Vishwakarma >Assignee: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.1 > > Attachments: SOLR-13410.patch, SOLR-13410.patch, SOLR-13410.patch, > overseerElection.log > > > Whenever a designated overseer node is restarted and overseer role is added > back if a designated node is not overseer leader following tasks take place: > 1. one by one nodes from electionNodes list become leader and ask designated > node `to come join election at head` > 2. current overseer node Fires Quit command and exits from Overseer Loop > 3. Next node from `Overseer Loop` becomes leader repeats steps 1,2 until > designated overseer node becomes the leader > Problem with above flow: OverseerNodePrioritizer is not able to add > `designated node` at the head of electionNodes list > Steps to reproduce: > # Setup solrcloud with 5 nodes, including one designated overseer > # Restart overseer container > Attached relevant logs -- 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
Socket Timeouts
I'm working with a client that's trying to process a lot of data (billions
of docs) via a streaming expression, and the initial query is (not
surprisingly) taking a long time. Lots of various types of timeouts have
been cropping up and I've found myself thinking I solved some only to
discover that the settings in solr.xml are far less wide reaching than I
thought initially. The present 5% scale cluster seems to hit one particular
time out about 50% of the time which has made it particularly confusing.
I'm guessing it's probably depending on something like how busy the
virtualization in Amazon is, just barely making it when it gets more
resources and timing out if anything is starved.
As I look around the code base I'm finding a LOT of places where timeouts
on SolrClients and CloudSolrClients are just arbitrarily set to one-off
constant values. The one bugging me right now is
public abstract class SolrClientBuilder> {
protected HttpClient httpClient;
protected ResponseParser responseParser;
protected Integer connectionTimeoutMillis = 15000;
protected Integer socketTimeoutMillis = 12;
Which I am unable to change because of this code in SolrStream:
/**
* Opens the stream to a single Solr instance.
**/
public void open() throws IOException {
if(cache == null) {
client = new HttpSolrClient.Builder(baseUrl).build();
} else {
client = cache.getHttpSolrClient(baseUrl);
}
I need to make this particular case configurable, so that I can get results
from a very long running query, but I sense that there is a much wider
problem in that we don't seem to have any organized plan for how socket
timeouts are set/managed in the code.
What thoughts have people had on this front?
-Gus
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
[GitHub] [lucene-solr] dweiss commented on issue #657: LUCENE-8781: FST direct arc addressing
dweiss commented on issue #657: LUCENE-8781: FST direct arc addressing URL: https://github.com/apache/lucene-solr/pull/657#issuecomment-489445325 It all looks good, Mike. There is one remaining thing -- to add a changes.txt entry in Lucene (under "improvements" section, I think). Add yourself as author of the patch, please. 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Call for help: moving from ant build to gradle
I don’t know enough about the differences to even think consider complaining. Is the proposal that we use Gradle for master and continue to use ant for 8x? As long as the two build systems can exist side by side (i.e. we can build master by executing some Gradle target and continue to build 8x with Ant like we always have) the minor inconvenience doesn’t merit standing in the way of progress. If that’s the case I don’t particularly care if we continue to use Ant with 8x forever. Or maybe some ambitious person can work on bringing 8x to Gradle after it has some mileage on master. And I have great faith that you wouldn’t be putting in the work unless you thought it was worth it ;) Erick > On May 4, 2019, at 10:31 PM, Mark Miller wrote: > > We already dump out to groovy to do anything interesting, so I doubt there is > much we can't replicate. > > - Mark > > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya > wrote: > Would beasting of tests be possible through gradle? > > On Sun, May 5, 2019 at 7:33 AM Mark Miller wrote: > > > > I looked into this a little more. > > > > Seems if we just do it with master and going forward, we don’t need multi > > version support - Uwe seems to have taken it out with the move to Java 11? > > > > I can handle regenerate. > > > > The other quality checks shouldn’t be crazy. > > > > So I guess we can probably do this, but before I focus on BS details, > > please speak up if you hate the idea of Gradle and you have the clout to > > stop it. > > > > > > Mark > > > > > > > > > > On Sat, May 4, 2019 at 5:56 PM Mark Miller wrote: > >> > >> I've got my own lucene-solr gradle branch as well. > >> > >> I stole the BuildPlugin and CheckWorkingCopy from Dat's branch, but also > >> made some changes. > >> > >> * Similar to above above, I don't move the src files so it can keep things > >> up to date without lots of pain. > >> * I used a plugin that lets us define versions in a root props file like > >> we currently do and ensures we use the same versions in all modules even > >> after auto conflict resolution (unlike gradle by default) > >> * It also locks versions so we can continue to pay attention to scary > >> automatic dependency resolution changes > >> * implementation and api used instead of compile > >> * Things build and the majority of tests pass (Lucene's TestVirtualMethod > >> does not for example) > >> > >> If someone like Uwe is serious about helping out with fun extras > >> (regenerating sources, extracting data from ICU, quality checks, > >> documentation (XSLT)), I'd look at contributing. > >> > >> - Mark > >> > >> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh > >> wrote: > >>> > >>> Cool Diego, > >>> > >>> I will take a look on this. Thanks a lot! > >> > >> > >> > >> -- > >> - Mark > >> > >> http://about.me/markrmiller > > > > -- > > - Mark > > > > http://about.me/markrmiller > > > -- > - Mark > > http://about.me/markrmiller - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11) - Build # 24038 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24038/ Java: 64bit/jdk-11 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test Error Message: Error from server at http://127.0.0.1:34287/collection1: non ok status: 500, message:Server Error Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:34287/collection1: non ok status: 500, message:Server Error at __randomizedtesting.SeedInfo.seed([5ED2CBFBFD74E21B:D686F42153888FE3]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:579) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224) at org.apache.solr.BaseDistributedSearchTestCase.add(BaseDistributedSearchTestCase.java:576) at org.apache.solr.cloud.NestedShardedAtomicUpdateTest.indexDocAndRandomlyCommit(NestedShardedAtomicUpdateTest.java:221) at org.apache.solr.cloud.NestedShardedAtomicUpdateTest.sendWrongRouteParam(NestedShardedAtomicUpdateTest.java:191) at org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test(NestedShardedAtomicUpdateTest.java:55) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at
[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 91 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/91/ 9 tests failed. FAILED: org.apache.solr.cloud.RollingRestartTest.test Error Message: Timeout occurred while waiting response from server at: http://127.0.0.1:44734 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: http://127.0.0.1:44734 at __randomizedtesting.SeedInfo.seed([DCE78960684CF7B7:54B3B6BAC6B09A4F]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:660) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1068) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:837) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:769) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224) at org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:74) at org.apache.solr.cloud.RollingRestartTest.test(RollingRestartTest.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at
[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk1.8.0_201) - Build # 517 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/517/ Java: 64bit/jdk1.8.0_201 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test Error Message: Error from server at http://127.0.0.1:42113/collection1: non ok status: 500, message:Server Error Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:42113/collection1: non ok status: 500, message:Server Error at __randomizedtesting.SeedInfo.seed([D5D89237C1EE64B4:5D8CADED6F12094C]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:579) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224) at org.apache.solr.BaseDistributedSearchTestCase.add(BaseDistributedSearchTestCase.java:576) at org.apache.solr.cloud.NestedShardedAtomicUpdateTest.indexDocAndRandomlyCommit(NestedShardedAtomicUpdateTest.java:221) at org.apache.solr.cloud.NestedShardedAtomicUpdateTest.sendWrongRouteParam(NestedShardedAtomicUpdateTest.java:191) at org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test(NestedShardedAtomicUpdateTest.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS-EA] Lucene-Solr-8.x-Linux (64bit/jdk-13-ea+18) - Build # 516 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/516/ Java: 64bit/jdk-13-ea+18 -XX:-UseCompressedOops -XX:+UseG1GC 8 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest Error Message: SOLR-11606: ByteBuddy used by Mockito is not working with this JVM version. Stack Trace: org.junit.AssumptionViolatedException: SOLR-11606: ByteBuddy used by Mockito is not working with this JVM version. at __randomizedtesting.SeedInfo.seed([EDC7A9059E037DDB]:0) at com.carrotsearch.randomizedtesting.RandomizedTest.assumeNoException(RandomizedTest.java:742) at org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:374) at org.apache.solr.update.processor.DistributedUpdateProcessorTest.beforeClass(DistributedUpdateProcessorTest.java:60) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:878) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:835) Caused by: java.lang.IllegalArgumentException: Unknown Java version: 13 at net.bytebuddy.ClassFileVersion.ofJavaVersion(ClassFileVersion.java:210) at net.bytebuddy.ClassFileVersion$VersionLocator$ForJava9CapableVm.locate(ClassFileVersion.java:462) at net.bytebuddy.ClassFileVersion.ofThisVm(ClassFileVersion.java:223) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:372) ... 24 more FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([EDC7A9059E037DDB]:0) at org.apache.solr.update.processor.DistributedUpdateProcessorTest.AfterClass(DistributedUpdateProcessorTest.java:67) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at
[JENKINS] Lucene-Solr-NightlyTests-8.1 - Build # 26 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.1/26/ 3 tests failed. FAILED: org.apache.solr.cloud.OverseerRolesTest.testDesignatedOverseerRestarts Error Message: Timed out waiting for overseer state change. The current overseer is: 127.0.0.1:37891_solr Stack Trace: java.lang.AssertionError: Timed out waiting for overseer state change. The current overseer is: 127.0.0.1:37891_solr at __randomizedtesting.SeedInfo.seed([462D0E631CD1476A:4E0C193C228F5560]:0) at org.junit.Assert.fail(Assert.java:88) at org.apache.solr.cloud.OverseerRolesTest.waitForNewOverseer(OverseerRolesTest.java:70) at org.apache.solr.cloud.OverseerRolesTest.waitForNewOverseer(OverseerRolesTest.java:75) at org.apache.solr.cloud.OverseerRolesTest.testDesignatedOverseerRestarts(OverseerRolesTest.java:189) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.ReindexCollectionTest.testLossySchema
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 353 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/353/ 1 tests failed. FAILED: org.apache.solr.cloud.ReindexCollectionTest.testBasicReindexing Error Message: num docs expected:<200> but was:<199> Stack Trace: java.lang.AssertionError: num docs expected:<200> but was:<199> at __randomizedtesting.SeedInfo.seed([C69E5467232E827D:553C9B882BC75645]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.apache.solr.cloud.ReindexCollectionTest.indexDocs(ReindexCollectionTest.java:376) at org.apache.solr.cloud.ReindexCollectionTest.testBasicReindexing(ReindexCollectionTest.java:123) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:834) Build Log: [...truncated 13095 lines...] [junit4] Suite: org.apache.solr.cloud.ReindexCollectionTest [junit4] 2> 709572 INFO
[jira] [Commented] (LUCENE-8791) Add CollectorRescorer
[
https://issues.apache.org/jira/browse/LUCENE-8791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833258#comment-16833258
]
Elbek Kamoliddinov commented on LUCENE-8791:
[~atris]
Hi Atri, Thanks for taking a look at the patch. So added more doc also renamed
{{Job}} and {{Jobs}} to {{SegmentRescorer}} and {{RescorerTask}} respectively,
hopefully this is more descriptive. I left {{docIDs}} as it is, this looks like
pretty standard.
I am not sure if I got the point here:
{quote}In general, I am a bit unsure about the class name and description. The
class advertises to be a Collector based rescorer implementation, whereas the
only constructor of the class takes a CollectorManager instance, which is
specific to parallel segments traversal. Should the class say that it is used
for parallel rescoring of hits across multiple segments?
{quote}
Yes, it takes {{CollectorManager}} instance and it is all it needs. Also It
makes sense to me that constructor takes {{CollectorManager}} because without
it, there is no point of creating {{CollectorRescorer}}. Also as you see It
doesn't necessarily only run in parallel. if {{ExecutorService}} is null then
it runs sequential, so calling it parallel would be wrong. JavaDoc on
constructor highlights this.
{quote}I am a bit wary of the way the patch maps the global jobs array to jobs
associated with segments belonging to one slice. In particular, buildJobs
method does not consider leaf ordinal during assigning values to the global
array, but rescore depends on that during retrieval.
{quote}
Good one, Corrected it to use ord based assignment.
Thanks.
> Add CollectorRescorer
> -
>
> Key: LUCENE-8791
> URL: https://issues.apache.org/jira/browse/LUCENE-8791
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Elbek Kamoliddinov
>Priority: Major
> Attachments: LUCENE-8791.patch, LUCENE-8791.patch
>
>
> This is another implementation of query rescorer api (LUCENE-5489). It adds
> rescoring functionality based on provided CollectorManager.
>
--
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
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 24036 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24036/ Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:+UseCompressedOops -XX:+UseG1GC 12 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest Error Message: SOLR-11606: ByteBuddy used by Mockito is not working with this JVM version. Stack Trace: org.junit.AssumptionViolatedException: SOLR-11606: ByteBuddy used by Mockito is not working with this JVM version. at __randomizedtesting.SeedInfo.seed([A08C5ADDDC40D1F6]:0) at com.carrotsearch.randomizedtesting.RandomizedTest.assumeNoException(RandomizedTest.java:742) at org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:374) at org.apache.solr.update.processor.DistributedUpdateProcessorTest.beforeClass(DistributedUpdateProcessorTest.java:60) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:878) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:830) Caused by: java.lang.IllegalArgumentException: Unknown Java version: 13 at net.bytebuddy.ClassFileVersion.ofJavaVersion(ClassFileVersion.java:210) at net.bytebuddy.ClassFileVersion$VersionLocator$ForJava9CapableVm.locate(ClassFileVersion.java:462) at net.bytebuddy.ClassFileVersion.ofThisVm(ClassFileVersion.java:223) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:372) ... 24 more FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([A08C5ADDDC40D1F6]:0) at org.apache.solr.update.processor.DistributedUpdateProcessorTest.AfterClass(DistributedUpdateProcessorTest.java:67) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
[jira] [Updated] (LUCENE-8791) Add CollectorRescorer
[ https://issues.apache.org/jira/browse/LUCENE-8791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elbek Kamoliddinov updated LUCENE-8791: --- Attachment: LUCENE-8791.patch > Add CollectorRescorer > - > > Key: LUCENE-8791 > URL: https://issues.apache.org/jira/browse/LUCENE-8791 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Elbek Kamoliddinov >Priority: Major > Attachments: LUCENE-8791.patch, LUCENE-8791.patch > > > This is another implementation of query rescorer api (LUCENE-5489). It adds > rescoring functionality based on provided CollectorManager. > -- 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
