[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 71 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/71/ 1 tests failed. FAILED: org.apache.solr.update.TestInPlaceUpdatesDistrib.test Error Message: Timeout occurred while waiting response from server at: http://127.0.0.1:39267/_gz/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: http://127.0.0.1:39267/_gz/collection1 at __randomizedtesting.SeedInfo.seed([DD76BADA1310DA95:55228500BDECB76D]: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.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224) at org.apache.solr.update.TestInPlaceUpdatesDistrib.addDocAndGetVersion(TestInPlaceUpdatesDistrib.java:1156) at org.apache.solr.update.TestInPlaceUpdatesDistrib.buildRandomIndex(TestInPlaceUpdatesDistrib.java:1201) at org.apache.solr.update.TestInPlaceUpdatesDistrib.docValuesUpdateTest(TestInPlaceUpdatesDistrib.java:351) at org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:162) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.c
[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11
[ https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816867#comment-16816867 ] Uwe Schindler commented on LUCENE-8738: --- OK, so I will commit this to the Java 11 branch, so we are in-line with Java 8. Everything else should be done in a separate JIRA issue. > Bump minimum Java version requirement to 11 > --- > > Key: LUCENE-8738 > URL: https://issues.apache.org/jira/browse/LUCENE-8738 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Adrien Grand >Priority: Minor > Labels: Java11 > Fix For: master (9.0) > > Attachments: LUCENE-8738-solr-CoreCloseListener.patch > > > See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq. -- 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-8738) Bump minimum Java version requirement to 11
[ https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816870#comment-16816870 ] ASF subversion and git services commented on LUCENE-8738: - Commit 13f8d1ead9fbc6ecb2206813284b8c08d1f37995 in lucene-solr's branch refs/heads/jira/LUCENE-8738 from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=13f8d1e ] LUCENE-8738: Port TransientSolrCoreCache observer pattern to Java 11 > Bump minimum Java version requirement to 11 > --- > > Key: LUCENE-8738 > URL: https://issues.apache.org/jira/browse/LUCENE-8738 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Adrien Grand >Priority: Minor > Labels: Java11 > Fix For: master (9.0) > > Attachments: LUCENE-8738-solr-CoreCloseListener.patch > > > See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq. -- 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] (SOLR-13400) Replace Obeservable pattern in TransientSolrCoreCache
Uwe Schindler created SOLR-13400: Summary: Replace Obeservable pattern in TransientSolrCoreCache Key: SOLR-13400 URL: https://issues.apache.org/jira/browse/SOLR-13400 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Server, SolrCloud Affects Versions: 8.0, master (9.0) Reporter: Uwe Schindler Due to change to Java 11 as minimum version (LUCENE-8738), the usage of the old java.utilObservable pattern is deprecated and cannot be used anymore in Lucene/Solr. LUCENE-8738 added a rewritten, more type-safe oimplementation of the observer pattern, but it looks like the is overengenieered. As there is only one listener registered, it would be enough to just call the method on SolrCores class (pkg-protected). On LUCENE-8738, Erick suggested to move the callback method to queue closes of core in CoreContainer instead, so all the abstractions can be removed. -- 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-8738) Bump minimum Java version requirement to 11
[ https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816875#comment-16816875 ] Uwe Schindler commented on LUCENE-8738: --- I opened SOLR-13400. > Bump minimum Java version requirement to 11 > --- > > Key: LUCENE-8738 > URL: https://issues.apache.org/jira/browse/LUCENE-8738 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Adrien Grand >Priority: Minor > Labels: Java11 > Fix For: master (9.0) > > Attachments: LUCENE-8738-solr-CoreCloseListener.patch > > > See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq. -- 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-13400) Replace Obeservable pattern in TransientSolrCoreCache
[ https://issues.apache.org/jira/browse/SOLR-13400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-13400: - Description: Due to change to Java 11 as minimum version (LUCENE-8738), the usage of the old java.utilObservable pattern is deprecated and cannot be used anymore in Lucene/Solr. LUCENE-8738 added a rewritten, more type-safe oimplementation of the observer pattern, but it looks like the is overengenieered. As there is only one listener registered, it would be enough to just call the method on SolrCores class (pkg-protected). On LUCENE-8738, [~erickerickson] suggested to move the callback method to queue closes of core in CoreContainer instead, so all the abstractions can be removed. was: Due to change to Java 11 as minimum version (LUCENE-8738), the usage of the old java.utilObservable pattern is deprecated and cannot be used anymore in Lucene/Solr. LUCENE-8738 added a rewritten, more type-safe oimplementation of the observer pattern, but it looks like the is overengenieered. As there is only one listener registered, it would be enough to just call the method on SolrCores class (pkg-protected). On LUCENE-8738, Erick suggested to move the callback method to queue closes of core in CoreContainer instead, so all the abstractions can be removed. > Replace Obeservable pattern in TransientSolrCoreCache > - > > Key: SOLR-13400 > URL: https://issues.apache.org/jira/browse/SOLR-13400 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Server, SolrCloud >Affects Versions: 8.0, master (9.0) >Reporter: Uwe Schindler >Priority: Major > > Due to change to Java 11 as minimum version (LUCENE-8738), the usage of the > old java.utilObservable pattern is deprecated and cannot be used anymore in > Lucene/Solr. > LUCENE-8738 added a rewritten, more type-safe oimplementation of the observer > pattern, but it looks like the is overengenieered. As there is only one > listener registered, it would be enough to just call the method on SolrCores > class (pkg-protected). On LUCENE-8738, [~erickerickson] suggested to move the > callback method to queue closes of core in CoreContainer instead, so all the > abstractions can be removed. -- 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-13336) maxBooleanClauses ignored; can result in exponential expansion of naive queries
[
https://issues.apache.org/jira/browse/SOLR-13336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816878#comment-16816878
]
Lucene/Solr QA commented on SOLR-13336:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
9s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check configsets' lucene version
{color} | {color:green} 1m 37s{color} | {color:green} the patch passed {color}
|
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate ref guide {color} |
{color:green} 1m 37s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 45m
56s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 5m
37s{color} | {color:green} solrj in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 59m 37s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13336 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12965763/SOLR-13336.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns checkluceneversion validaterefguide |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon
Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 6e28cd6 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_191 |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/372/testReport/ |
| modules | C: solr/core solr/server solr/solrj solr/solr-ref-guide U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/372/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> maxBooleanClauses ignored; can result in exponential expansion of naive
> queries
> ---
>
> Key: SOLR-13336
> URL: https://issues.apache.org/jira/browse/SOLR-13336
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.0, 7.6, master (9.0)
>Reporter: Michael Gibney
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13336.patch, SOLR-13336.patch, SOLR-13336.patch
>
>
> Since SOLR-10921 it appears that Solr always sets
> {{BooleanQuery.maxClauseCount}} (at the Lucene level) to
> {{Integer.MAX_VALUE-1}}. I assume this is because Solr parses
> {{maxBooleanClauses}} out of the config and applies it externally.
> In any case, when used as part of
> {{lucene.util.QueryBuilder.analyzeGraphPhrase}} (and possibly other places?),
> the Lucene code checks internally against only the static {{maxClauseCount}}
> variable (permanently set to {{Integer.MAX_VALUE-1}} in the context of Solr).
> Thus in at least one case ({{analyzeGraphPhrase()}}, but possibly others?),
> {{maxBooleanClauses}} is having no effect. I'm pretty sure this is what's
> underlying the [issue reported here as being related to Solr
> 7.6|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201902.mbox/%3CCAF%3DheHE6-MOtn2XRbEg7%3D1tpNEGtE8GaChnOhFLPeJzpF18SGA%40mail.gmail.com%3E].
> To summarize, users are definitely susceptible (to varying degrees of likely
[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11
[ https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816877#comment-16816877 ] Uwe Schindler commented on LUCENE-8738: --- I think we can merge this branch. > Bump minimum Java version requirement to 11 > --- > > Key: LUCENE-8738 > URL: https://issues.apache.org/jira/browse/LUCENE-8738 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Adrien Grand >Priority: Minor > Labels: Java11 > Fix For: master (9.0) > > Attachments: LUCENE-8738-solr-CoreCloseListener.patch > > > See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq. -- 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 # 23911 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23911/ Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:+UseCompressedOops -XX:+UseParallelGC 5 tests failed. FAILED: org.apache.lucene.document.TestLatLonShapeEncoding.testRandomLineEncoding Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([58677E73732CA050:B57EC6B1A74AFA31]:0) at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertTrue(Assert.java:52) at org.apache.lucene.document.TestLatLonShapeEncoding.verifyEncoding(TestLatLonShapeEncoding.java:533) at org.apache.lucene.document.TestLatLonShapeEncoding.testRandomLineEncoding(TestLatLonShapeEncoding.java:475) 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.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 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) FAILED: org.apache.lucene.document.TestLatLonShapeEncoding.testRandomLineEncoding Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([58677E73732CA050:B57EC6B1A74AFA31]:0) at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertTrue(Assert.java:52) at org.apache.lucene.document.TestLatLonShapeEncoding.verifyEncoding(TestLatLonShapeEncoding.java:533) at org.apache.lucen
[jira] [Commented] (LUCENE-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816891#comment-16816891
]
Tomoko Uchida commented on LUCENE-8752:
---
Hi [~thetaphi],
current directory structure is slightly different from what I thought. I put
the patch file into {{src/tools/patches}} directory. What do you think of this?
{code:java}
lucene$ tree -L 4 analysis/kuromoji/
analysis/kuromoji/
└── src
├── java
│ ├── org
│ │ └── apache
│ └── overview.html
├── resources
│ ├── META-INF
│ │ └── services
│ └── org
│ └── apache
├── test
│ └── org
│ └── apache
└── tools
├── java
│ └── org
├── patches
│ └── Noun.proper.csv.patch
└── test
└── org
{code}
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816898#comment-16816898
]
Uwe Schindler commented on LUCENE-8752:
---
That's how I would do it! +1
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816900#comment-16816900
]
Uwe Schindler commented on LUCENE-8752:
---
So lets just squash-merge it into master and 8.x.
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816905#comment-16816905
]
Tomoko Uchida commented on LUCENE-8752:
---
Thanks, [~thetaphi],
I will (squash) merge it soon.
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-8738) Bump minimum Java version requirement to 11
[ https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816914#comment-16816914 ] Uwe Schindler commented on LUCENE-8738: --- I'd suggest to somehow coordinate that change, because we have to update Jenkins jobs. I already created the scripts on Policeman Jenkins that uses Java 11 or later only during randomization. I just have to update the jobs. How about sending a warning message to all commiters and give some date/time for the change? E.g., Monday afternoon 15:00 CEST? > Bump minimum Java version requirement to 11 > --- > > Key: LUCENE-8738 > URL: https://issues.apache.org/jira/browse/LUCENE-8738 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Adrien Grand >Priority: Minor > Labels: Java11 > Fix For: master (9.0) > > Attachments: LUCENE-8738-solr-CoreCloseListener.patch > > > See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq. -- 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-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816923#comment-16816923
]
ASF subversion and git services commented on LUCENE-8752:
-
Commit 7619c07d3a80bb781f688c2cbbff33024142670a in lucene-solr's branch
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7619c07 ]
LUCENE-8752: Add Japanese new imperial era '令和' (Reiwa) to the dictionary used
in JapaneseTokenizer
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816924#comment-16816924
]
ASF subversion and git services commented on LUCENE-8752:
-
Commit 3a00fd1acb9e097e50f642612fe89ebc8958cc80 in lucene-solr's branch
refs/heads/branch_8x from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3a00fd1 ]
LUCENE-8752: Add Japanese new imperial era '令和' (Reiwa) to the dictionary used
in JapaneseTokenizer
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816929#comment-16816929
]
Tomoko Uchida commented on LUCENE-8752:
---
Here is the patch: [^LUCENE-8752.patch] from the pull request. (I cannot add
"Issue Links" for some reason...)
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: LUCENE-8752.patch
>
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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] [Resolved] (LUCENE-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida resolved LUCENE-8752.
---
Resolution: Fixed
Fix Version/s: master (9.0)
8.1
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8752.patch
>
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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
[GitHub] [lucene-solr] mocobeta closed pull request #632: LUCENE-8752: Add a Kuromoji dictionary entry for Japanese new era 令和(Reiwa)
mocobeta closed pull request #632: LUCENE-8752: Add a Kuromoji dictionary entry for Japanese new era 令和(Reiwa) URL: https://github.com/apache/lucene-solr/pull/632 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
[GitHub] [lucene-solr] mocobeta commented on issue #632: LUCENE-8752: Add a Kuromoji dictionary entry for Japanese new era 令和(Reiwa)
mocobeta commented on issue #632: LUCENE-8752: Add a Kuromoji dictionary entry for Japanese new era 令和(Reiwa) URL: https://github.com/apache/lucene-solr/pull/632#issuecomment-482805606 This was merged to master & branch_8x. 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-13345) Admin UI login page doesn't accept empty passwords
[ https://issues.apache.org/jira/browse/SOLR-13345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816933#comment-16816933 ] Märt commented on SOLR-13345: - I have the following use case: # version control contains solr config with preconfigured schema and security.json (BasicAuthPlugin+RuleBasedAuthorizationPlugin preconfigured with an empty password). # CI deploys the product to the customer # as one time initialization, the customer sends a single request to solr to change the password. everything else is already preconfigured. In the development environments, changing the password is not necessary as nothing sensitive is indexed. So we just skip changing the password and use the empty password. This way the dev environment is identical to the customer's with no manual steps required. One could argue that we could set the initial password to "password" or "12345", but this wouldn't make anything more secure and simply make the developer login more inconvenient. Thank you for considering the issue > Admin UI login page doesn't accept empty passwords > -- > > Key: SOLR-13345 > URL: https://issues.apache.org/jira/browse/SOLR-13345 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 7.7, 8.0 >Reporter: Märt >Priority: Minor > > In solr 7.6 and older, it was possible to log in with an empty password using > basic auth. The new Admin UI login page implemented in SOLR-7896 no longer > accepts empty passwords. > This issue was discussed in the solr-user mailing list > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201903.mbox/%3C7629BDDD-3D22-4203-9188-0E0A8DCF2FEE%40cominvent.com%3E -- 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-master-Linux (64bit/jdk-11) - Build # 23912 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23912/ Java: 64bit/jdk-11 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test Error Message: Error from server at http://127.0.0.1:41473/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:41473/collection1: non ok status: 500, message:Server Error at __randomizedtesting.SeedInfo.seed([923402274493D0AF:1A603DFDEA6FBD57]: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 com.carrotsearch.randomizedtesting.rules.Statemen
[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk1.8.0_172) - Build # 394 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/394/
Java: 64bit/jdk1.8.0_172 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC
1 tests failed.
FAILED: org.apache.solr.handler.TestSolrConfigHandlerCloud.test
Error Message:
Could not get expected value 'A val' for path 'response/params/x/a' full
output: { "responseHeader":{ "status":0, "QTime":0},
"response":{"znodeVersion":-1}}, from server:
https://127.0.0.1:38229/qgh/q/collection1_shard2_replica_n2
Stack Trace:
java.lang.AssertionError: Could not get expected value 'A val' for path
'response/params/x/a' full output: {
"responseHeader":{
"status":0,
"QTime":0},
"response":{"znodeVersion":-1}}, from server:
https://127.0.0.1:38229/qgh/q/collection1_shard2_replica_n2
at
__randomizedtesting.SeedInfo.seed([9B5A812717145FAD:130EBEFDB9E83255]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:590)
at
org.apache.solr.handler.TestSolrConfigHandlerCloud.testReqParams(TestSolrConfigHandlerCloud.java:112)
at
org.apache.solr.handler.TestSolrConfigHandlerCloud.test(TestSolrConfigHandlerCloud.java:51)
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
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.uti
[jira] [Assigned] (SOLR-13400) Replace Obeservable pattern in TransientSolrCoreCache
[ https://issues.apache.org/jira/browse/SOLR-13400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson reassigned SOLR-13400: - Assignee: Erick Erickson Preliminary patch. It compiles and TestLazyCores runs, but that's all I've tested so far. Needs some polish, but the idea looks good. > Replace Obeservable pattern in TransientSolrCoreCache > - > > Key: SOLR-13400 > URL: https://issues.apache.org/jira/browse/SOLR-13400 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Server, SolrCloud >Affects Versions: 8.0, master (9.0) >Reporter: Uwe Schindler >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13400.patch > > > Due to change to Java 11 as minimum version (LUCENE-8738), the usage of the > old java.utilObservable pattern is deprecated and cannot be used anymore in > Lucene/Solr. > LUCENE-8738 added a rewritten, more type-safe oimplementation of the observer > pattern, but it looks like the is overengenieered. As there is only one > listener registered, it would be enough to just call the method on SolrCores > class (pkg-protected). On LUCENE-8738, [~erickerickson] suggested to move the > callback method to queue closes of core in CoreContainer instead, so all the > abstractions can be removed. -- 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-13400) Replace Obeservable pattern in TransientSolrCoreCache
[ https://issues.apache.org/jira/browse/SOLR-13400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-13400: -- Attachment: SOLR-13400.patch > Replace Obeservable pattern in TransientSolrCoreCache > - > > Key: SOLR-13400 > URL: https://issues.apache.org/jira/browse/SOLR-13400 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Server, SolrCloud >Affects Versions: 8.0, master (9.0) >Reporter: Uwe Schindler >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13400.patch > > > Due to change to Java 11 as minimum version (LUCENE-8738), the usage of the > old java.utilObservable pattern is deprecated and cannot be used anymore in > Lucene/Solr. > LUCENE-8738 added a rewritten, more type-safe oimplementation of the observer > pattern, but it looks like the is overengenieered. As there is only one > listener registered, it would be enough to just call the method on SolrCores > class (pkg-protected). On LUCENE-8738, [~erickerickson] suggested to move the > callback method to queue closes of core in CoreContainer instead, so all the > abstractions can be removed. -- 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] [Comment Edited] (SOLR-13400) Replace Obeservable pattern in TransientSolrCoreCache
[ https://issues.apache.org/jira/browse/SOLR-13400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816974#comment-16816974 ] Erick Erickson edited comment on SOLR-13400 at 4/13/19 3:15 PM: Preliminary patch. It compiles and TestLazyCores runs, but that's all I've tested so far. Needs some polish, but the idea looks good. Oh, and this is PoC, it will have to be reworked when LUCENE-8738 is merged was (Author: erickerickson): Preliminary patch. It compiles and TestLazyCores runs, but that's all I've tested so far. Needs some polish, but the idea looks good. > Replace Obeservable pattern in TransientSolrCoreCache > - > > Key: SOLR-13400 > URL: https://issues.apache.org/jira/browse/SOLR-13400 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Server, SolrCloud >Affects Versions: 8.0, master (9.0) >Reporter: Uwe Schindler >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13400.patch > > > Due to change to Java 11 as minimum version (LUCENE-8738), the usage of the > old java.utilObservable pattern is deprecated and cannot be used anymore in > Lucene/Solr. > LUCENE-8738 added a rewritten, more type-safe oimplementation of the observer > pattern, but it looks like the is overengenieered. As there is only one > listener registered, it would be enough to just call the method on SolrCores > class (pkg-protected). On LUCENE-8738, [~erickerickson] suggested to move the > callback method to queue closes of core in CoreContainer instead, so all the > abstractions can be removed. -- 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-master-Linux (64bit/jdk-12) - Build # 23913 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23913/ Java: 64bit/jdk-12 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.DirectoryFactoryTest Error Message: The test or suite printed 8554 bytes to stdout and stderr, even though the limit was set to 8192 bytes. Increase the limit with @Limit, ignore it completely with @SuppressSysoutChecks or run with -Dtests.verbose=true Stack Trace: java.lang.AssertionError: The test or suite printed 8554 bytes to stdout and stderr, even though the limit was set to 8192 bytes. Increase the limit with @Limit, ignore it completely with @SuppressSysoutChecks or run with -Dtests.verbose=true at __randomizedtesting.SeedInfo.seed([6C749486925CACA1]:0) at org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:282) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37) 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) Build Log: [...truncated 14090 lines...] [junit4] Suite: org.apache.solr.core.DirectoryFactoryTest [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=521327504 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=1676276290 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=287027861 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=1065044411 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=922518423 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=439028968 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=1458084386 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=867907541 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=1628039694 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=587720331 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=824987971 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=1539558700 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=1974736320 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=1771800131 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=980317306 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContainer was not close prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!! instance=2130797750 [junit4] 2> 888751 ERROR (Finalizer) [] o.a.s.c.CoreContainer CoreContaine
[JENKINS] Lucene-Solr-repro - Build # 3163 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-repro/3163/
[...truncated 29 lines...]
[repro] Jenkins log URL:
https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/71/consoleText
[repro] Revision: 811aae60cd79b9e5e931516219de7e7f10363bed
[repro] Ant options: -Dtests.multiplier=2
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
[repro] Repro line: ant test -Dtestcase=TestInPlaceUpdatesDistrib
-Dtests.method=test -Dtests.seed=DD76BADA1310DA95 -Dtests.multiplier=2
-Dtests.nightly=true -Dtests.slow=true
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
-Dtests.locale=ja-JP-u-ca-japanese-x-lvariant-JP -Dtests.timezone=Asia/Bangkok
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[repro] Encountered IncompleteRead exception, pausing and then retrying...
[repro] Jenkins log URL:
https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/71/consoleText
[repro] Revision: 811aae60cd79b9e5e931516219de7e7f10363bed
[repro] Ant options: -Dtests.multiplier=2
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
[repro] Encountered IncompleteRead exception, pausing and then retrying...
[repro] Jenkins log URL:
https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/71/consoleText
[repro] Revision: 811aae60cd79b9e5e931516219de7e7f10363bed
[repro] Ant options: -Dtests.multiplier=2
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
[repro] Encountered IncompleteRead exception, aborting after too many retries.
[...truncated 64 lines...]
raise RuntimeError('ERROR: fetching %s : %s' % (url, e))
RuntimeError: ERROR: fetching
https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/71/consoleText :
IncompleteRead(0 bytes read)
Build step 'Execute shell' 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] (LUCENE-8736) LatLonShapePolygonQuery returning incorrect WITHIN results with shared boundaries
[
https://issues.apache.org/jira/browse/LUCENE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817013#comment-16817013
]
Robert Muir commented on LUCENE-8736:
-
I guess I don't see them as boundary failures. Instead just a very fancy way of
implementing that ancient point in poly algorithm :)
The main thing is that its very well-defined. Its also extremely easy to reason
about not just in the case of partitioning into a graph (or multipolygon), but
also complex polygons with holes and stuff like that. E.g. if we use shapes of
countries, any given point can only be in one country, and this kind of thing
simplifies corner cases.
> LatLonShapePolygonQuery returning incorrect WITHIN results with shared
> boundaries
> -
>
> Key: LUCENE-8736
> URL: https://issues.apache.org/jira/browse/LUCENE-8736
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8736.patch, LUCENE-8736.patch,
> adaptive-decoding.patch
>
>
> Triangles that are {{WITHIN}} a target polygon query that also share a
> boundary with the polygon are incorrectly reported as {{CROSSES}} instead of
> {{INSIDE}}. This leads to incorrect {{WITHIN}} query results as demonstrated
> in the following test:
> {code:java}
> public void testWithinFailure() throws Exception {
> Directory dir = newDirectory();
> RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> // test polygons:
> Polygon indexPoly1 = new Polygon(new double[] {4d, 4d, 3d, 3d, 4d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly2 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {6d, 7d, 7d, 6d, 6d});
> Polygon indexPoly3 = new Polygon(new double[] {1d, 1d, 0d, 0d, 1d}, new
> double[] {3d, 4d, 4d, 3d, 3d});
> Polygon indexPoly4 = new Polygon(new double[] {2d, 2d, 1d, 1d, 2d}, new
> double[] {0d, 1d, 1d, 0d, 0d});
> // index polygons:
> Document doc;
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly1);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly2);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly3);
> w.addDocument(doc);
> addPolygonsToDoc(FIELDNAME, doc = new Document(), indexPoly4);
> w.addDocument(doc);
> / search //
> IndexReader reader = w.getReader();
> w.close();
> IndexSearcher searcher = newSearcher(reader);
> Polygon[] searchPoly = new Polygon[] {new Polygon(new double[] {4d, 4d,
> 0d, 0d, 4d}, new double[] {0d, 7d, 7d, 0d, 0d})};
> Query q = LatLonShape.newPolygonQuery(FIELDNAME, QueryRelation.WITHIN,
> searchPoly);
> assertEquals(4, searcher.count(q));
> IOUtils.close(w, reader, dir);
> }
> {code}
--
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] [Comment Edited] (LUCENE-8738) Bump minimum Java version requirement to 11
[ https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816914#comment-16816914 ] Uwe Schindler edited comment on LUCENE-8738 at 4/13/19 5:51 PM: I'd suggest to somehow coordinate that change, because we have to update Jenkins jobs. I already created the scripts on Policeman Jenkins that uses Java 11 or later only during randomization. I just have to update the jobs. How about sending a warning message to all commiters and give some date/time for the change? E.g., Monday afternoon 15:00 CEST? Unfortunately I have to disable "master" builds on Solaris x86 then - I cannot get any JDK version installable there. AdoptOpenJDK is not yet released. was (Author: thetaphi): I'd suggest to somehow coordinate that change, because we have to update Jenkins jobs. I already created the scripts on Policeman Jenkins that uses Java 11 or later only during randomization. I just have to update the jobs. How about sending a warning message to all commiters and give some date/time for the change? E.g., Monday afternoon 15:00 CEST? > Bump minimum Java version requirement to 11 > --- > > Key: LUCENE-8738 > URL: https://issues.apache.org/jira/browse/LUCENE-8738 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Adrien Grand >Priority: Minor > Labels: Java11 > Fix For: master (9.0) > > Attachments: LUCENE-8738-solr-CoreCloseListener.patch > > > See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq. -- 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-13400) Replace Obeservable pattern in TransientSolrCoreCache
[ https://issues.apache.org/jira/browse/SOLR-13400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817027#comment-16817027 ] Uwe Schindler commented on SOLR-13400: -- +1 patch looks fine. I think adoption to jdk 11 is now trivial, as most of the patch is already there. Do we plan to simplify this also in Solr 8.1 ? > Replace Obeservable pattern in TransientSolrCoreCache > - > > Key: SOLR-13400 > URL: https://issues.apache.org/jira/browse/SOLR-13400 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Server, SolrCloud >Affects Versions: 8.0, master (9.0) >Reporter: Uwe Schindler >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13400.patch > > > Due to change to Java 11 as minimum version (LUCENE-8738), the usage of the > old java.utilObservable pattern is deprecated and cannot be used anymore in > Lucene/Solr. > LUCENE-8738 added a rewritten, more type-safe oimplementation of the observer > pattern, but it looks like the is overengenieered. As there is only one > listener registered, it would be enough to just call the method on SolrCores > class (pkg-protected). On LUCENE-8738, [~erickerickson] suggested to move the > callback method to queue closes of core in CoreContainer instead, so all the > abstractions can be removed. -- 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-13400) Replace Observable pattern in TransientSolrCoreCache
[ https://issues.apache.org/jira/browse/SOLR-13400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-13400: - Summary: Replace Observable pattern in TransientSolrCoreCache (was: Replace Obeservable pattern in TransientSolrCoreCache) > Replace Observable pattern in TransientSolrCoreCache > > > Key: SOLR-13400 > URL: https://issues.apache.org/jira/browse/SOLR-13400 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Server, SolrCloud >Affects Versions: 8.0, master (9.0) >Reporter: Uwe Schindler >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13400.patch > > > Due to change to Java 11 as minimum version (LUCENE-8738), the usage of the > old java.utilObservable pattern is deprecated and cannot be used anymore in > Lucene/Solr. > LUCENE-8738 added a rewritten, more type-safe oimplementation of the observer > pattern, but it looks like the is overengenieered. As there is only one > listener registered, it would be enough to just call the method on SolrCores > class (pkg-protected). On LUCENE-8738, [~erickerickson] suggested to move the > callback method to queue closes of core in CoreContainer instead, so all the > abstractions can be removed. -- 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-13400) Replace Observable pattern in TransientSolrCoreCache
[ https://issues.apache.org/jira/browse/SOLR-13400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817028#comment-16817028 ] Uwe Schindler commented on SOLR-13400: -- One thing: Please update the Javadocs of abstract base class! > Replace Observable pattern in TransientSolrCoreCache > > > Key: SOLR-13400 > URL: https://issues.apache.org/jira/browse/SOLR-13400 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Server, SolrCloud >Affects Versions: 8.0, master (9.0) >Reporter: Uwe Schindler >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13400.patch > > > Due to change to Java 11 as minimum version (LUCENE-8738), the usage of the > old java.utilObservable pattern is deprecated and cannot be used anymore in > Lucene/Solr. > LUCENE-8738 added a rewritten, more type-safe oimplementation of the observer > pattern, but it looks like the is overengenieered. As there is only one > listener registered, it would be enough to just call the method on SolrCores > class (pkg-protected). On LUCENE-8738, [~erickerickson] suggested to move the > callback method to queue closes of core in CoreContainer instead, so all the > abstractions can be removed. -- 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-master-Linux (64bit/jdk-11.0.2) - Build # 23914 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23914/ Java: 64bit/jdk-11.0.2 -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:36107/g_uwi/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:36107/g_uwi/collection1: non ok status: 500, message:Server Error at __randomizedtesting.SeedInfo.seed([5E6DFD7B65DDB154:D639C2A1CB21DCAC]: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 com.carrotsearch.randomizedte
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1819 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1819/ 2 tests failed. FAILED: org.apache.solr.cloud.UnloadDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=21888, name=testExecutor-5499-thread-8, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=21888, name=testExecutor-5499-thread-8, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] at __randomizedtesting.SeedInfo.seed([9EEA7954F2B4B0C1:16BE468E5C48DD39]:0) Caused by: java.lang.RuntimeException: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: http://127.0.0.1:36019/nvro/f at __randomizedtesting.SeedInfo.seed([9EEA7954F2B4B0C1]:0) at org.apache.solr.cloud.BasicDistributedZkTest.lambda$createCollectionInOneInstance$1(BasicDistributedZkTest.java:658) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: http://127.0.0.1:36019/nvro/f 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.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224) at org.apache.solr.cloud.BasicDistributedZkTest.lambda$createCollectionInOneInstance$1(BasicDistributedZkTest.java:656) ... 4 more Caused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at java.net.SocketInputStream.read(SocketInputStream.java:171) at java.net.SocketInputStream.read(SocketInputStream.java:141) at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137) at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153) at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163) at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:548) ... 9 more FAILED: junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsChaosMonkeySafeLeaderTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [NRTCachingDirectory] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.NRTCachingDirectory at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:99) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:779) at org.apache.solr.core.SolrCore.(SolrCore.java:976) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreC
[jira] [Created] (LUCENE-8763) Update to OpenClover that works with Java 11
Uwe Schindler created LUCENE-8763: - Summary: Update to OpenClover that works with Java 11 Key: LUCENE-8763 URL: https://issues.apache.org/jira/browse/LUCENE-8763 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: master (9.0) Reporter: Uwe Schindler Assignee: Uwe Schindler OpenClover does not yet have a release that works with Java 11, so we have to disable the task and add a TODO for updating it. I will commit this for now to the LUCENE-8738 branch. -- 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-8738) Bump minimum Java version requirement to 11
[ https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817058#comment-16817058 ] Uwe Schindler commented on LUCENE-8738: --- I just figured out: OpenClover has no release yet with Java 11. I opened a new issue: LUCENE-8763 For now I will disable the task an Jenkins jobs using Clover. > Bump minimum Java version requirement to 11 > --- > > Key: LUCENE-8738 > URL: https://issues.apache.org/jira/browse/LUCENE-8738 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Adrien Grand >Priority: Minor > Labels: Java11 > Fix For: master (9.0) > > Attachments: LUCENE-8738-solr-CoreCloseListener.patch > > > See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq. -- 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-8763) Update to OpenClover that works with Java 11
[ https://issues.apache.org/jira/browse/LUCENE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817061#comment-16817061 ] ASF subversion and git services commented on LUCENE-8763: - Commit 831e940e02305eef6d99799bc1ba52e62d7190f5 in lucene-solr's branch refs/heads/jira/LUCENE-8738 from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=831e940 ] LUCENE-8738, LUCENE-8763: Disable OpenClover until a release with Java 11 support is available > Update to OpenClover that works with Java 11 > > > Key: LUCENE-8763 > URL: https://issues.apache.org/jira/browse/LUCENE-8763 > Project: Lucene - Core > Issue Type: Bug > Components: general/build >Affects Versions: master (9.0) >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > > OpenClover does not yet have a release that works with Java 11, so we have to > disable the task and add a TODO for updating it. > I will commit this for now to the LUCENE-8738 branch. -- 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-8738) Bump minimum Java version requirement to 11
[ https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817060#comment-16817060 ] ASF subversion and git services commented on LUCENE-8738: - Commit 831e940e02305eef6d99799bc1ba52e62d7190f5 in lucene-solr's branch refs/heads/jira/LUCENE-8738 from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=831e940 ] LUCENE-8738, LUCENE-8763: Disable OpenClover until a release with Java 11 support is available > Bump minimum Java version requirement to 11 > --- > > Key: LUCENE-8738 > URL: https://issues.apache.org/jira/browse/LUCENE-8738 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Adrien Grand >Priority: Minor > Labels: Java11 > Fix For: master (9.0) > > Attachments: LUCENE-8738-solr-CoreCloseListener.patch > > > See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq. -- 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-master-Windows (64bit/jdk-9.0.4) - Build # 7882 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7882/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.impl.CloudSolrClientTest Error Message: ObjectTracker found 4 object(s) that were not released!!! [MockDirectoryWrapper, InternalHttpClient, SolrCore, MockDirectoryWrapper] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:509) at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:351) at org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:422) at org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$13(ReplicationHandler.java:1191) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:300) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base/java.lang.Thread.run(Thread.java:844) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.http.impl.client.InternalHttpClient at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:321) at org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:330) at org.apache.solr.handler.IndexFetcher.createHttpClient(IndexFetcher.java:230) at org.apache.solr.handler.IndexFetcher.(IndexFetcher.java:272) at org.apache.solr.handler.ReplicationHandler.inform(ReplicationHandler.java:1222) at org.apache.solr.cloud.ReplicateFromLeader.startReplication(ReplicateFromLeader.java:109) at org.apache.solr.cloud.ZkController.startReplicationFromLeader(ZkController.java:1307) at org.apache.solr.cloud.ZkController.register(ZkController.java:1263) at org.apache.solr.cloud.ZkController.register(ZkController.java:1148) at org.apache.solr.core.ZkContainer.lambda$registerInZk$0(ZkContainer.java:190) at org.apache.solr.core.ZkContainer.registerInZk(ZkContainer.java:222) at org.apache.solr.core.CoreContainer.registerCore(CoreContainer.java:1072) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1234) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1134) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base/java.lang.Thread.run(Thread.java:844) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.core.SolrCore at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.SolrCore.(SolrCore.java:1063) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1224) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1134) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.
[jira] [Updated] (LUCENE-8763) Update to OpenClover that works with Java 11
[ https://issues.apache.org/jira/browse/LUCENE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-8763: -- Labels: Java11 (was: ) > Update to OpenClover that works with Java 11 > > > Key: LUCENE-8763 > URL: https://issues.apache.org/jira/browse/LUCENE-8763 > Project: Lucene - Core > Issue Type: Bug > Components: general/build >Affects Versions: master (9.0) >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > Labels: Java11 > > OpenClover does not yet have a release that works with Java 11, so we have to > disable the task and add a TODO for updating it. > I will commit this for now to the LUCENE-8738 branch. -- 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-8738) Bump minimum Java version requirement to 11
[ https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817078#comment-16817078 ] Uwe Schindler commented on LUCENE-8738: --- The Maven builds are not yet working, as we have to raise minimum Maven version and also update some (many) plugins. > Bump minimum Java version requirement to 11 > --- > > Key: LUCENE-8738 > URL: https://issues.apache.org/jira/browse/LUCENE-8738 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Adrien Grand >Priority: Minor > Labels: Java11 > Fix For: master (9.0) > > Attachments: LUCENE-8738-solr-CoreCloseListener.patch > > > See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq. -- 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] [Comment Edited] (LUCENE-8738) Bump minimum Java version requirement to 11
[ https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817078#comment-16817078 ] Uwe Schindler edited comment on LUCENE-8738 at 4/13/19 8:24 PM: The Maven builds are not yet working, as we have to raise minimum Maven version and also update some (many) plugins. I will work on it tomorrow. was (Author: thetaphi): The Maven builds are not yet working, as we have to raise minimum Maven version and also update some (many) plugins. > Bump minimum Java version requirement to 11 > --- > > Key: LUCENE-8738 > URL: https://issues.apache.org/jira/browse/LUCENE-8738 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Adrien Grand >Priority: Minor > Labels: Java11 > Fix For: master (9.0) > > Attachments: LUCENE-8738-solr-CoreCloseListener.patch > > > See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq. -- 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-8738) Bump minimum Java version requirement to 11
[ https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817079#comment-16817079 ] Uwe Schindler commented on LUCENE-8738: --- In the meantime I updated all Jenkins jobs on Policeman Jenkins and ASF Jenkins to user Java 11+ on master. I disabled all jobs, which wont work yet (Clover and Maven). So we can merge the branch without breaking Jenkins. > Bump minimum Java version requirement to 11 > --- > > Key: LUCENE-8738 > URL: https://issues.apache.org/jira/browse/LUCENE-8738 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Adrien Grand >Priority: Minor > Labels: Java11 > Fix For: master (9.0) > > Attachments: LUCENE-8738-solr-CoreCloseListener.patch > > > See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq. -- 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-8.x-Windows (64bit/jdk-9.0.4) - Build # 196 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/196/ Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly Error Message: We should have more counts for boolean fields! expected:<[bool]GSL> but was:<[int]GSL> Stack Trace: org.junit.ComparisonFailure: We should have more counts for boolean fields! expected:<[bool]GSL> but was:<[int]GSL> at __randomizedtesting.SeedInfo.seed([E0764FC96F4A477:95BC0AA4DBAC9629]:0) at org.junit.Assert.assertEquals(Assert.java:115) at org.apache.solr.cloud.DocValuesNotIndexedTest.doGroupingDvOnly(DocValuesNotIndexedTest.java:385) at org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:322) 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:564) 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:844) Build Log: [...truncated 14082 lines...] [junit4] Suite: org.apache.solr.cloud.DocValuesNotIndexedTest [junit4] 2> Creati
[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11
[ https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817113#comment-16817113 ] ASF subversion and git services commented on LUCENE-8738: - Commit e23fd230a0dedf80ea94b9e2f32f1b9b3c122122 in lucene-solr's branch refs/heads/jira/LUCENE-8738 from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e23fd23 ] LUCENE-8738: Update Maven build > Bump minimum Java version requirement to 11 > --- > > Key: LUCENE-8738 > URL: https://issues.apache.org/jira/browse/LUCENE-8738 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Adrien Grand >Priority: Minor > Labels: Java11 > Fix For: master (9.0) > > Attachments: LUCENE-8738-solr-CoreCloseListener.patch > > > See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq. -- 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-12860) MetricsHistoryHandler does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817115#comment-16817115
]
ASF subversion and git services commented on SOLR-12860:
Commit f2c59db2736ecdded9601acf0549094769781a4a in lucene-solr's branch
refs/heads/jira/LUCENE-8738 from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f2c59db ]
SOLR-12860: MetricsHistoryHandler now always uses PKI Auth (#642)
* SOLR-12860: MetricsHistoryHandler now uses PKI Auth for metrics collection in
background thread
> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, metrics
>Affects Versions: 7.4
>Reporter: Varun Thacker
>Assignee: Jan Høydahl
>Priority: Critical
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-12028_metics_handler_not_work_basic_auth.patch,
> SOLR-12860.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then
> uploaded the default security.json from
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>
> I'm seeing errors like these in the logs which would indicate that the
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN (MetricsHistoryHandler-12-thread-1) [ ]
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://192.168.0.8:7574/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
> require authentication
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-c
[jira] [Commented] (SOLR-13391) Add variance and standard deviation stream evaluators
[ https://issues.apache.org/jira/browse/SOLR-13391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817118#comment-16817118 ] ASF subversion and git services commented on SOLR-13391: Commit 58001bfc870a6f5f04cc200853df7ffe04473866 in lucene-solr's branch refs/heads/jira/LUCENE-8738 from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=58001bf ] SOLR-13391: Add variance and standard deviation stream evaluators Squashed commit of the following: commit 406d4b959a42e4830ac1c52836ccbcfc1b614b46 Author: Nazerke Date: Fri Apr 12 14:03:34 2019 +0200 added missing package commit 32c239687c39c5da3e4f2d0f25df73127331fa99 Author: Nazerke Date: Fri Apr 12 14:03:14 2019 +0200 added package commit 7b3f9bd415002969a4ec5d87a9ffbfd6fcff6e92 Author: Nazerke Date: Fri Apr 12 14:02:28 2019 +0200 added var and stddev functions commit 77c4f9fdd9f111862a55b645aad960457291414c Author: Nazerke Date: Fri Apr 12 14:00:59 2019 +0200 added test for the variance and standard deviation stream evaluators commit 2d9692c178590b65e46cfd9e04ca0384c7d39ec5 Author: naz Date: Wed Apr 10 19:50:30 2019 +0200 added var and stddev new evaluators commit d265225747bce9a0eabd713994ddd4990dbbbfa2 Author: naz Date: Wed Apr 10 19:49:23 2019 +0200 variance streaming evaluator commit a3330064bb62b5723b9125334ef1d61fc3b098d3 Author: naz Date: Wed Apr 10 19:49:02 2019 +0200 standard deviation streaming evaluator > Add variance and standard deviation stream evaluators > - > > Key: SOLR-13391 > URL: https://issues.apache.org/jira/browse/SOLR-13391 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: streaming expressions >Reporter: Nazerke Seidan >Priority: Minor > Labels: pull-request-available > Fix For: 8.1 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > It seems variance and standard deviation stream evaluators are not supported > by any of the solr version. For example, > let(echo="m,v,sd", arr=array(1,3,3), m=mean(a), v=var(a), > sd=stddev(a)) > So far, only the mean function is implemented. I think it is useful to have > var and sttdev functions separately as a stream evaluator. -- 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-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817121#comment-16817121 ] ASF subversion and git services commented on LUCENE-2562: - Commit f85c08224b47e10f3482f27f3811b44dcae3be59 in lucene-solr's branch refs/heads/jira/LUCENE-8738 from Tomoko Uchida [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f85c082 ] LUCENE-2562: Luke has no Maven artifacts > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Assignee: Tomoko Uchida >Priority: Major > Labels: gsoc2014 > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, > Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, > luke-javafx2.png, luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, > lukeALE-documents.png, screenshot-1.png, スクリーンショット 2018-11-05 9.19.47.png > > Time Spent: 50m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- 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-12860) MetricsHistoryHandler does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817116#comment-16817116
]
ASF subversion and git services commented on SOLR-12860:
Commit f2c59db2736ecdded9601acf0549094769781a4a in lucene-solr's branch
refs/heads/jira/LUCENE-8738 from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f2c59db ]
SOLR-12860: MetricsHistoryHandler now always uses PKI Auth (#642)
* SOLR-12860: MetricsHistoryHandler now uses PKI Auth for metrics collection in
background thread
> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, metrics
>Affects Versions: 7.4
>Reporter: Varun Thacker
>Assignee: Jan Høydahl
>Priority: Critical
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-12028_metics_handler_not_work_basic_auth.patch,
> SOLR-12860.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then
> uploaded the default security.json from
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>
> I'm seeing errors like these in the logs which would indicate that the
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN (MetricsHistoryHandler-12-thread-1) [ ]
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://192.168.0.8:7574/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
> require authentication
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-c
[jira] [Commented] (SOLR-13398) Move log "Processing SSL Credential Provider chain" from INFO to DEBUG
[
https://issues.apache.org/jira/browse/SOLR-13398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817117#comment-16817117
]
ASF subversion and git services commented on SOLR-13398:
Commit 03f5a5e7a1d75d6502087dbcc1ca86450875a233 in lucene-solr's branch
refs/heads/jira/LUCENE-8738 from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=03f5a5e ]
SOLR-13398: Move log "Processing SSL Credential Provider chain" from INFO to
DEBUG to prevent leaking into bin/solr printout
> Move log "Processing SSL Credential Provider chain" from INFO to DEBUG
> --
>
> Key: SOLR-13398
> URL: https://issues.apache.org/jira/browse/SOLR-13398
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: logging
>Affects Versions: 8.0
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.1
>
>
> Move log "Processing SSL Credential Provider chain" from INFO to DEBUG to
> prevent this log line leaking into Terminal prompt when using {{bin/solr}}.
--
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-13366) AutoScalingConfig 'Invalid stage name' warnings after upgrade
[
https://issues.apache.org/jira/browse/SOLR-13366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817120#comment-16817120
]
ASF subversion and git services commented on SOLR-13366:
Commit fe1a1094763a8b21c11a9a21ed81df46e5e135e7 in lucene-solr's branch
refs/heads/jira/LUCENE-8738 from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fe1a109 ]
SOLR-13366: Clarify 'Invalid stage name' warning logging in AutoScalingConfig
> AutoScalingConfig 'Invalid stage name' warnings after upgrade
> -
>
> Key: SOLR-13366
> URL: https://issues.apache.org/jira/browse/SOLR-13366
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13366.patch, SOLR-13366.patch
>
>
> I noticed WARNings like this in some of our logs:
> {code:java}
> ... OverseerAutoScalingTriggerThread ... o.a.s.c.s.c.a.AutoScalingConfig
> Invalid stage name '.auto_add_replicas.system' in listener config, skipping:
> {beforeAction=[], afterAction=[], trigger=.auto_add_replicas, stage=[WAITING,
> STARTED, ABORTED, SUCCEEDED, FAILED, BEFORE_ACTION, AFTER_ACTION],
> class=org.apache.solr.cloud.autoscaling.SystemLogListener}
> {code}
> After some detective work I think I've tracked this down to 7.1.0
> [TriggerEventProcessorStage|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.1.0/solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/TriggerEventProcessorStage.java]
> having a {{WAITING}} stage and that stage having been removed in 7.2.0
> [TriggerEventProcessorStage|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.2.0/solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/TriggerEventProcessorStage.java]
> via the SOLR-11320 changes. Haven't tried to reproduce it but my theory is
> that the listener got auto-created (with the {{WAITING}} stage) when the
> cloud was running pre-7.2.0 code and then after upgrading the warnings start
> to appear.
--
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-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817123#comment-16817123
]
ASF subversion and git services commented on LUCENE-8752:
-
Commit 7619c07d3a80bb781f688c2cbbff33024142670a in lucene-solr's branch
refs/heads/jira/LUCENE-8738 from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7619c07 ]
LUCENE-8752: Add Japanese new imperial era '令和' (Reiwa) to the dictionary used
in JapaneseTokenizer
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8752.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-13391) Add variance and standard deviation stream evaluators
[ https://issues.apache.org/jira/browse/SOLR-13391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817119#comment-16817119 ] ASF subversion and git services commented on SOLR-13391: Commit 6c62fbf25f13b1078bb89f3eef8386a10f197b5a in lucene-solr's branch refs/heads/jira/LUCENE-8738 from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6c62fbf ] SOLR-13391: Update CHANGES.txt > Add variance and standard deviation stream evaluators > - > > Key: SOLR-13391 > URL: https://issues.apache.org/jira/browse/SOLR-13391 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: streaming expressions >Reporter: Nazerke Seidan >Priority: Minor > Labels: pull-request-available > Fix For: 8.1 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > It seems variance and standard deviation stream evaluators are not supported > by any of the solr version. For example, > let(echo="m,v,sd", arr=array(1,3,3), m=mean(a), v=var(a), > sd=stddev(a)) > So far, only the mean function is implemented. I think it is useful to have > var and sttdev functions separately as a stream evaluator. -- 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-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817122#comment-16817122 ] ASF subversion and git services commented on LUCENE-2562: - Commit 6e28cd60a8247ad1339bea2ae9dfbb912507594b in lucene-solr's branch refs/heads/jira/LUCENE-8738 from Tomoko Uchida [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6e28cd6 ] LUCENE-2562: Fix smoker for 'luke' module. > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Assignee: Tomoko Uchida >Priority: Major > Labels: gsoc2014 > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, > Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, > luke-javafx2.png, luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, > lukeALE-documents.png, screenshot-1.png, スクリーンショット 2018-11-05 9.19.47.png > > Time Spent: 50m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- 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-8738) Bump minimum Java version requirement to 11
[ https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817124#comment-16817124 ] ASF subversion and git services commented on LUCENE-8738: - Commit e5f733d74bdac4d15f2e989fab0fbbf5ba0da0d8 in lucene-solr's branch refs/heads/jira/LUCENE-8738 from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e5f733d ] Merge branch 'master' of https://gitbox.apache.org/repos/asf/lucene-solr into jira/LUCENE-8738 > Bump minimum Java version requirement to 11 > --- > > Key: LUCENE-8738 > URL: https://issues.apache.org/jira/browse/LUCENE-8738 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Adrien Grand >Priority: Minor > Labels: Java11 > Fix For: master (9.0) > > Attachments: LUCENE-8738-solr-CoreCloseListener.patch > > > See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq. -- 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-8738) Bump minimum Java version requirement to 11
[ https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817132#comment-16817132 ] Uwe Schindler commented on LUCENE-8738: --- I fixed the Maven build, seems to works now (excluding tests, dont work yet - but that's the same on master). > Bump minimum Java version requirement to 11 > --- > > Key: LUCENE-8738 > URL: https://issues.apache.org/jira/browse/LUCENE-8738 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Adrien Grand >Priority: Minor > Labels: Java11 > Fix For: master (9.0) > > Attachments: LUCENE-8738-solr-CoreCloseListener.patch > > > See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq. -- 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-master-MacOSX (64bit/jdk-11.0.2) - Build # 5089 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5089/ Java: 64bit/jdk-11.0.2 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.update.processor.CategoryRoutedAliasUpdateProcessorTest.testSliceRouting Error Message: Timeout occurred while waiting response from server at: http://127.0.0.1:52534/solr/myAlias__CRA__Heart_of_Gold_shard3_replica_n14 Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Timeout occurred while waiting response from server at: http://127.0.0.1:52534/solr/myAlias__CRA__Heart_of_Gold_shard3_replica_n14 at __randomizedtesting.SeedInfo.seed([D0D7822E5C2F031F:E1470EC2F879FC36]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.getRouteException(CloudSolrClient.java:125) at org.apache.solr.client.solrj.impl.CloudSolrClient.getRouteException(CloudSolrClient.java:46) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.directUpdate(BaseCloudSolrClient.java:485) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:964) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:830) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:763) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:177) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138) at org.apache.solr.update.processor.CategoryRoutedAliasUpdateProcessorTest.testSliceRouting(CategoryRoutedAliasUpdateProcessorTest.java:371) 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.carro
[jira] [Commented] (LUCENE-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817139#comment-16817139
]
ASF subversion and git services commented on LUCENE-8752:
-
Commit b60548f6d88bc1e3bba9916fc19d1c90b6505e28 in lucene-solr's branch
refs/heads/master from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b60548f ]
LUCENE-8752: Fix precommit error: patch files cannot have a license header
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8752.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817140#comment-16817140
]
ASF subversion and git services commented on LUCENE-8752:
-
Commit 6e030338864eb8b0ef9ddfd7f40df5030ab1d92a in lucene-solr's branch
refs/heads/branch_8x from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6e03033 ]
LUCENE-8752: Fix precommit error: patch files cannot have a license header
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8752.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-Tests-master - Build # 3270 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3270/ 1 tests failed. FAILED: org.apache.solr.security.AuditLoggerIntegrationTest.testAsyncQueueDrain Error Message: Expecting <2 callbacks in buffer, was 2 Stack Trace: java.lang.AssertionError: Expecting <2 callbacks in buffer, was 2 at __randomizedtesting.SeedInfo.seed([78BC7EA61C64BE62:C9A38182ACA72DBD]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.apache.solr.security.AuditLoggerIntegrationTest.testAsyncQueueDrain(AuditLoggerIntegrationTest.java:128) 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 13262 lines...] [junit4] Suite: org.apache.solr.security.AuditLoggerIntegrationTest [junit4] 2> Creating dataDir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build/solr-core/test/J1/temp/solr.security.AuditLoggerIntegrationTest_78BC7EA61C64BE62-001/init-core-data-001 [junit
[jira] [Commented] (LUCENE-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817143#comment-16817143
]
ASF subversion and git services commented on LUCENE-8752:
-
Commit 7830cae571e5f4a326ccce55a095060a314dd9d4 in lucene-solr's branch
refs/heads/master from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7830cae ]
LUCENE-8752: Add license header to patch file
Revert "LUCENE-8752: Fix precommit error: patch files cannot have a license
header" - This reverts commit b60548f6d88bc1e3bba9916fc19d1c90b6505e28.
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8752.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817142#comment-16817142
]
ASF subversion and git services commented on LUCENE-8752:
-
Commit 7830cae571e5f4a326ccce55a095060a314dd9d4 in lucene-solr's branch
refs/heads/master from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7830cae ]
LUCENE-8752: Add license header to patch file
Revert "LUCENE-8752: Fix precommit error: patch files cannot have a license
header" - This reverts commit b60548f6d88bc1e3bba9916fc19d1c90b6505e28.
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8752.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817145#comment-16817145
]
ASF subversion and git services commented on LUCENE-8752:
-
Commit a4ba4b0b7c81c10c0f078a094a0ad1ba3453d633 in lucene-solr's branch
refs/heads/branch_8x from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a4ba4b0 ]
LUCENE-8752: Add license header to patch file
Revert "LUCENE-8752: Fix precommit error: patch files cannot have a license
header" - This reverts commit b60548f6d88bc1e3bba9916fc19d1c90b6505e28.
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8752.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817144#comment-16817144
]
ASF subversion and git services commented on LUCENE-8752:
-
Commit a4ba4b0b7c81c10c0f078a094a0ad1ba3453d633 in lucene-solr's branch
refs/heads/branch_8x from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a4ba4b0 ]
LUCENE-8752: Add license header to patch file
Revert "LUCENE-8752: Fix precommit error: patch files cannot have a license
header" - This reverts commit b60548f6d88bc1e3bba9916fc19d1c90b6505e28.
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8752.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817146#comment-16817146
]
Uwe Schindler commented on LUCENE-8752:
---
Hi [~Tomoko Uchida],
there was a RAT error during precommit task, because a license header was
missing on the patch file.
In a first try i just disabled the license checks for the patches folder - but
i found out that the patch tool ignores anything before the +++/--- lines of
the patch. So I just added a ASF2 license header above the patch and reverted
my first commit.
As the file was patched by you and (the Lucene committers), the patch itsself
is licensed by ASF2 license.
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8752.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)
[
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817147#comment-16817147
]
Tomoko Uchida commented on LUCENE-8752:
---
[~thetaphi]: I pulled the changes and confirmed that the patch file with the
license header works correctly. Thank you.
> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和'
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8752.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa).
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It
> should be tokenized as one word so that Japanese texts including era names
> are searched as users expect. Because the default Kuromoji dictionary
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would
> be desirable the search systems properly handle this without adding a user
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>
--
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-13400) Replace Observable pattern in TransientSolrCoreCache
[ https://issues.apache.org/jira/browse/SOLR-13400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817166#comment-16817166 ] Erick Erickson commented on SOLR-13400: --- yeah, I'll backport this to 8, there's no good reason not to. And your Javadocs comment is well taken, I have to go over it all, I wanted to see if it was as straightforward as I thought. And, precommit and test both return SUCCESS. Thanks again for pointing this out. I've been assuming that doing this after the Java 11 push is the way to go, but that's not essential, whatever you would find easiest. I know, doing this originally would have been easiest, ;) > Replace Observable pattern in TransientSolrCoreCache > > > Key: SOLR-13400 > URL: https://issues.apache.org/jira/browse/SOLR-13400 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Server, SolrCloud >Affects Versions: 8.0, master (9.0) >Reporter: Uwe Schindler >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13400.patch > > > Due to change to Java 11 as minimum version (LUCENE-8738), the usage of the > old java.utilObservable pattern is deprecated and cannot be used anymore in > Lucene/Solr. > LUCENE-8738 added a rewritten, more type-safe oimplementation of the observer > pattern, but it looks like the is overengenieered. As there is only one > listener registered, it would be enough to just call the method on SolrCores > class (pkg-protected). On LUCENE-8738, [~erickerickson] suggested to move the > callback method to queue closes of core in CoreContainer instead, so all the > abstractions can be removed. -- 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-8.x-Linux (64bit/jdk-11.0.2) - Build # 397 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/397/ Java: 64bit/jdk-11.0.2 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.TestCloudRecovery2.test Error Message: Error from server at http://127.0.0.1:33853/solr: 100 Async exceptions during distributed update: java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused Stack Tr
[JENKINS] Lucene-Solr-Tests-8.x - Build # 126 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/126/ 1 tests failed. FAILED: org.apache.solr.cloud.MigrateRouteKeyTest.multipleShardMigrateTest Error Message: DocCount on target collection does not match expected:<19> but was:<0> Stack Trace: java.lang.AssertionError: DocCount on target collection does not match expected:<19> but was:<0> at __randomizedtesting.SeedInfo.seed([BD72F853C4A1DCED:A162E229E5616C0C]: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.MigrateRouteKeyTest.multipleShardMigrateTest(MigrateRouteKeyTest.java:163) 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 13223 lines...] [junit4] Suite: org.apache.solr.cloud.MigrateRouteKeyTest [junit4] 2> 790244 INFO (SUITE-MigrateRouteKeyTest-seed#[BD72F853C4A1DCED]-worker) [] o.a.
[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk-12) - Build # 191 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/191/ Java: 64bit/jdk-12 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=29473, name=OverseerCollectionConfigSetProcessor-72077840036790276-127.0.0.1:43823_-n_00, state=RUNNABLE, group=Overseer collection creation process.] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=29473, name=OverseerCollectionConfigSetProcessor-72077840036790276-127.0.0.1:43823_-n_00, state=RUNNABLE, group=Overseer collection creation process.] at __randomizedtesting.SeedInfo.seed([E0C836BF5DE13DD7:689C0965F31D502F]:0) Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded Build Log: [...truncated 14467 lines...] [junit4] Suite: org.apache.solr.cloud.BasicDistributedZkTest [junit4] 2> 1213343 INFO (SUITE-BasicDistributedZkTest-seed#[E0C836BF5DE13DD7]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.BasicDistributedZkTest_E0C836BF5DE13DD7-001/init-core-data-001 [junit4] 2> 1213343 WARN (SUITE-BasicDistributedZkTest-seed#[E0C836BF5DE13DD7]-worker) [] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=49 numCloses=49 [junit4] 2> 1213343 INFO (SUITE-BasicDistributedZkTest-seed#[E0C836BF5DE13DD7]-worker) [] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=false [junit4] 2> 1213343 INFO (SUITE-BasicDistributedZkTest-seed#[E0C836BF5DE13DD7]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: @org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl="https://issues.apache.org/jira/browse/SOLR-5776";) [junit4] 2> 1213344 INFO (SUITE-BasicDistributedZkTest-seed#[E0C836BF5DE13DD7]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2> 1213346 INFO (TEST-BasicDistributedZkTest.test-seed#[E0C836BF5DE13DD7]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 1213346 INFO (ZkTestServer Run Thread) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 1213346 INFO (ZkTestServer Run Thread) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 1213446 INFO (TEST-BasicDistributedZkTest.test-seed#[E0C836BF5DE13DD7]) [] o.a.s.c.ZkTestServer start zk server on port:35903 [junit4] 2> 1213446 INFO (TEST-BasicDistributedZkTest.test-seed#[E0C836BF5DE13DD7]) [] o.a.s.c.ZkTestServer parse host and port list: 127.0.0.1:35903 [junit4] 2> 1213446 INFO (TEST-BasicDistributedZkTest.test-seed#[E0C836BF5DE13DD7]) [] o.a.s.c.ZkTestServer connecting to 127.0.0.1 35903 [junit4] 2> 1213448 INFO (zkConnectionManagerCallback-11621-thread-1) [ ] o.a.s.c.c.ConnectionManager zkClient has connected [junit4] 2> 1213450 INFO (zkConnectionManagerCallback-11623-thread-1) [ ] o.a.s.c.c.ConnectionManager zkClient has connected [junit4] 2> 1213451 INFO (TEST-BasicDistributedZkTest.test-seed#[E0C836BF5DE13DD7]) [] o.a.s.c.ZkTestServer put /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2> 1213452 INFO (TEST-BasicDistributedZkTest.test-seed#[E0C836BF5DE13DD7]) [] o.a.s.c.ZkTestServer put /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/core/src/test-files/solr/collection1/conf/schema.xml to /configs/conf1/schema.xml [junit4] 2> 1213453 INFO (TEST-BasicDistributedZkTest.test-seed#[E0C836BF5DE13DD7]) [] o.a.s.c.ZkTestServer put /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml to /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 1213453 INFO (TEST-BasicDistributedZkTest.test-seed#[E0C836BF5DE13DD7]) [] o.a.s.c.ZkTestServer put /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/core/src/test-files/solr/collection1/conf/stopwords.txt to /configs/conf1/stopwords.txt [junit4] 2> 1213454 INFO (TEST-BasicDistributedZkTest.test-seed#[E0C836BF5DE13DD7]) [] o.a.s.c.ZkTestServer put /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/core/src/test-files/solr/collection1/conf/protwords.txt to /configs/conf1/protwords.txt [junit4] 2> 1213455 INFO (TEST-BasicDistributedZkTest.test-seed#[E0C836BF5DE13DD7]) [] o.a.s.c.ZkTestServer put /home/jenkins/workspace/Lucene-Solr-BadApples-master-Linux/solr/core/src/test-f
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-11.0.2) - Build # 7883 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7883/ Java: 64bit/jdk-11.0.2 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.update.processor.CategoryRoutedAliasUpdateProcessorTest.testSliceRouting Error Message: Timeout occurred while waiting response from server at: http://127.0.0.1:51008/solr/myAlias__CRA__Heart_of_Gold_shard3_replica_n14 Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Timeout occurred while waiting response from server at: http://127.0.0.1:51008/solr/myAlias__CRA__Heart_of_Gold_shard3_replica_n14 at __randomizedtesting.SeedInfo.seed([F2AF590CA9766237:C33FD5E00D209D1E]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.getRouteException(CloudSolrClient.java:125) at org.apache.solr.client.solrj.impl.CloudSolrClient.getRouteException(CloudSolrClient.java:46) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.directUpdate(BaseCloudSolrClient.java:485) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:964) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:830) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:763) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:177) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138) at org.apache.solr.update.processor.CategoryRoutedAliasUpdateProcessorTest.testSliceRouting(CategoryRoutedAliasUpdateProcessorTest.java:371) 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 c
