[JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk1.8.0) - Build # 272 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/272/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat

Error Message:
expected:<16> but was:<15>

Stack Trace:
java.lang.AssertionError: expected:<16> but was:<15>
at 
__randomizedtesting.SeedInfo.seed([DB6DC28D5560B1D2:E295833E1541FDB9]: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.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:677)
at 
org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:282)
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 

[jira] [Resolved] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets

[Tomoko Uchida (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomoko Uchida resolved LUCENE-8933.
---
   Resolution: Fixed
 Assignee: Tomoko Uchida
Fix Version/s: 8.3
   master (9.0)

I merged the PRs, one for master and one for 8.x.

> JapaneseTokenizer creates Token objects with corrupt offsets
> 
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0), 8.3
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> An Elasticsearch user reported the following stack trace when parsing 
> synonyms. It looks like the only reason why this might occur is if the offset 
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>  
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
>  ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f - 
> nknize - 2018-12-07 14:44:20]
> at 
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
>  ~[?:?]
> at 
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906844#comment-16906844
 ] 

ASF subversion and git services commented on LUCENE-8933:
-

Commit 0106b74badb98473e1e4464b8e2b37d7bebdc1a4 in lucene-solr's branch 
refs/heads/branch_8x from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0106b74 ]

LUCENE-8933: Validate JapaneseTokenizer user dictionary entry (for 8.x) (#810)




> JapaneseTokenizer creates Token objects with corrupt offsets
> 
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> An Elasticsearch user reported the following stack trace when parsing 
> synonyms. It looks like the only reason why this might occur is if the offset 
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>  
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
>  ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f - 
> nknize - 2018-12-07 14:44:20]
> at 
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
>  ~[?:?]
> at 
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] mocobeta merged pull request #810: LUCENE-8933: Validate JapaneseTokenizer user dictionary entry (for 8.x)

[GitBox]

mocobeta merged pull request #810: LUCENE-8933: Validate JapaneseTokenizer user 
dictionary entry (for 8.x)
URL: https://github.com/apache/lucene-solr/pull/810
 
 
   


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 a change in pull request #810: LUCENE-8933: Validate JapaneseTokenizer user dictionary entry (for 8.x)

[GitBox]

mocobeta commented on a change in pull request #810: LUCENE-8933: Validate 
JapaneseTokenizer user dictionary entry (for 8.x)
URL: https://github.com/apache/lucene-solr/pull/810#discussion_r313692958
 
 

 ##
 File path: 
lucene/analysis/kuromoji/src/test/org/apache/lucene/analysis/ja/dict/UserDictionaryTest.java
 ##
 @@ -77,4 +78,11 @@ public void testRead() throws IOException {
 UserDictionary dictionary = TestJapaneseTokenizer.readDict();
 assertNotNull(dictionary);
   }
+
+  @Test(expected = RuntimeException.class)
 
 Review comment:
   Thanks, fixed.


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 a change in pull request #809: LUCENE-8933: Validate JapaneseTokenizer user dictionary entry

[GitBox]

mocobeta commented on a change in pull request #809: LUCENE-8933: Validate 
JapaneseTokenizer user dictionary entry
URL: https://github.com/apache/lucene-solr/pull/809#discussion_r313692050
 
 

 ##
 File path: 
lucene/analysis/kuromoji/src/test/org/apache/lucene/analysis/ja/dict/UserDictionaryTest.java
 ##
 @@ -77,4 +78,19 @@ public void testRead() throws IOException {
 UserDictionary dictionary = TestJapaneseTokenizer.readDict();
 assertNotNull(dictionary);
   }
+
+  @Test(expected = RuntimeException.class)
 
 Review comment:
   Fixed in https://github.com/apache/lucene-solr/pull/830


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] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906841#comment-16906841
 ] 

ASF subversion and git services commented on LUCENE-8933:
-

Commit cdeb294236388a52fa9cc38152da16ea0be057dd in lucene-solr's branch 
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cdeb294 ]

LUCENE-8933: Use 'expectThrows' instead of 'expected'. (#830)



> JapaneseTokenizer creates Token objects with corrupt offsets
> 
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> An Elasticsearch user reported the following stack trace when parsing 
> synonyms. It looks like the only reason why this might occur is if the offset 
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>  
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
>  ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f - 
> nknize - 2018-12-07 14:44:20]
> at 
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
>  ~[?:?]
> at 
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] mocobeta merged pull request #830: LUCENE-8933: Use expectThrows instead of expected.

[GitBox]

mocobeta merged pull request #830: LUCENE-8933: Use expectThrows instead of 
expected.
URL: https://github.com/apache/lucene-solr/pull/830
 
 
   


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 opened a new pull request #830: LUCENE-8933: Use expectThrows instead of expected.

[GitBox]

mocobeta opened a new pull request #830: LUCENE-8933: Use expectThrows instead 
of expected.
URL: https://github.com/apache/lucene-solr/pull/830
 
 
   Use `LuceneTestCase#expectThrows()` instead of `expected`.


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-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906836#comment-16906836
 ] 

ASF subversion and git services commented on SOLR-13452:


Commit e45f99ebb8f03440b0985406ec188a81d320bf6b in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e45f99e ]

SOLR-13452: Remove this test, Uwe says it's no longer relevant.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] markrmiller opened a new pull request #829: SOLR-13452: Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[GitBox]

markrmiller opened a new pull request #829: SOLR-13452: Update the lucene-solr 
build from Ivy+Ant+Maven (shadow build) to Gradle.
URL: https://github.com/apache/lucene-solr/pull/829
 
 
   Just a sample PR to help look at changes.


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 a change in pull request #809: LUCENE-8933: Validate JapaneseTokenizer user dictionary entry

[GitBox]

mocobeta commented on a change in pull request #809: LUCENE-8933: Validate 
JapaneseTokenizer user dictionary entry
URL: https://github.com/apache/lucene-solr/pull/809#discussion_r313689721
 
 

 ##
 File path: 
lucene/analysis/kuromoji/src/test/org/apache/lucene/analysis/ja/dict/UserDictionaryTest.java
 ##
 @@ -77,4 +78,19 @@ public void testRead() throws IOException {
 UserDictionary dictionary = TestJapaneseTokenizer.readDict();
 assertNotNull(dictionary);
   }
+
+  @Test(expected = RuntimeException.class)
 
 Review comment:
   Sorry, I missed LuceneTestCase#expectThrows. Will fix this in another patch.


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] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906820#comment-16906820
 ] 

ASF subversion and git services commented on LUCENE-8933:
-

Commit 73ba88a50dec64f367caa88d277c26dfd1d8883b in lucene-solr's branch 
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=73ba88a ]

LUCENE-8933: Validate JapaneseTokenizer user dictionary entry (#809)

* LUCENE-8933: Validate JapaneseTokenizer user dictionary entry if the 
concatenated segment is same as its surface form.

> JapaneseTokenizer creates Token objects with corrupt offsets
> 
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> An Elasticsearch user reported the following stack trace when parsing 
> synonyms. It looks like the only reason why this might occur is if the offset 
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>  
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
>  ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f - 
> nknize - 2018-12-07 14:44:20]
> at 
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
>  ~[?:?]
> at 
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906819#comment-16906819
 ] 

ASF subversion and git services commented on LUCENE-8933:
-

Commit 73ba88a50dec64f367caa88d277c26dfd1d8883b in lucene-solr's branch 
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=73ba88a ]

LUCENE-8933: Validate JapaneseTokenizer user dictionary entry (#809)

* LUCENE-8933: Validate JapaneseTokenizer user dictionary entry if the 
concatenated segment is same as its surface form.

> JapaneseTokenizer creates Token objects with corrupt offsets
> 
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> An Elasticsearch user reported the following stack trace when parsing 
> synonyms. It looks like the only reason why this might occur is if the offset 
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>  
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
>  ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f - 
> nknize - 2018-12-07 14:44:20]
> at 
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
>  ~[?:?]
> at 
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13658) Precommit fail Java "var" until 9x. Fail "var...<>" constructs entirely

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906822#comment-16906822
 ] 

Mark Miller commented on SOLR-13658:


Weird keyword to single out IMO - non of the new features or keywords will work 
in a backport, it's happened before and before, what is different here?

What I got from Erick was that he didn't like that it's more difficult to 
determine the actual type visually, but as he mentioned, IDE's make this simple.

Personally, I'm still not a big var fan, but not sure why it should be banned 
anymore than other new stuff we start using in newer versions every time we 
jump up a Java version. Ban it all baby ;)


> Precommit fail Java "var" until 9x. Fail "var...<>" constructs entirely
> ---
>
> Key: SOLR-13658
> URL: https://issues.apache.org/jira/browse/SOLR-13658
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0), 8.2
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13658.patch, SOLR-13658.patch
>
>
> Personally, I'm strongly against allowing the "var" construct in Lucene/Solr 
> code. I think it's a wonderful opportunity to introduce bugs that won't be 
> found until runtime as well as making maintainence significantly harder. I 
> don't even think for a project like Solr it would save any time overall...
> So let's discuss this ahead of time and see if we can reach a consensus. I'll 
> start the discussion off:
> My baseline argument is that for a large complex project, especially ones 
> with many different people coding, I want the compiler to give me all the 
> help possible. And the "var" construct takes away some of that help.
> I’ve seen this argument go around at least 4 times in my career. The argument 
> that “it takes longer to write if you have to type all this stuff” is bogus. 
> Last I knew, 80% of the time spent is in maintaining/reading it. So the 
> argument “I can write faster” means I can save some fraction of the 20% of 
> the time writing the original code but spend many times that figuring out 
> what the code is actually doing the other 80% of the time.
> The IDE makes _writing_ this slightly faster, admittedly.
> {code:java}
> Whatever what = new Whatever();
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> {code}
> But once that’s done, if I’m reading the code again I don't have any clue what
> {code:java}
> kidding or blivet
> {code}
> are. Here's the signature for getComplex:
> {code:java}
> Map> getComplex()
> {code}
> I have to go over to the definition (which I admit is easier than it used to 
> be in the bad old days, but still) to find out.
> HERE'S THE PART I REALLY OBJECT TO!
> The above I could probably live with, maybe we could get the InteliJ 
> developers and see if they can make hover show the inference. What I will 
> kick and scream about is introducing bugs that are not found until runtime. 
> Even this obvious stupidity fails with a ClassCastException:
> {code:java}
> var corny = new TreeMap();
> corny.put("one", "two");
> corny.get(1);
> {code}
> But it's much worse when using classes from somewhere else. For instance, 
> change the underlying class in the first example to return
> {code:java}
> Map>{code}
> . 
>  This code that used to work now throws an error, _but it compiles_.
> {code:java}
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> var blah = kidding.get("stuff").get(1); //  generates ClassCastException: 
> class java.lang.String cannot be cast to class java.lang.Integer
> {code}
> So in order to save some time writing (that I claim will be lost multiple 
> times over when maintaining the code) we'll introduce run-time errors that 
> will take a bunch _more_ time to figure out, and won’t be found during unit 
> tests unless and until we have complete code coverage.
> If there's a way to insure that this kind of thing can't get into the code 
> and we implement that, I could be persuaded, but let's make that an explicit 
> requirement (and find a suitable task for the build system, precommit or 
> whatever).
> The floor is open...



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] mocobeta merged pull request #809: LUCENE-8933: Validate JapaneseTokenizer user dictionary entry

[GitBox]

mocobeta merged pull request #809: LUCENE-8933: Validate JapaneseTokenizer user 
dictionary entry
URL: https://github.com/apache/lucene-solr/pull/809
 
 
   


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 #809: LUCENE-8933: Validate JapaneseTokenizer user dictionary entry

[GitBox]

mocobeta commented on issue #809: LUCENE-8933: Validate JapaneseTokenizer user 
dictionary entry
URL: https://github.com/apache/lucene-solr/pull/809#issuecomment-521083020
 
 
   Thanks, I will merge it soon.


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 a change in pull request #809: LUCENE-8933: Validate JapaneseTokenizer user dictionary entry

[GitBox]

mocobeta commented on a change in pull request #809: LUCENE-8933: Validate 
JapaneseTokenizer user dictionary entry
URL: https://github.com/apache/lucene-solr/pull/809#discussion_r313686040
 
 

 ##
 File path: 
lucene/analysis/kuromoji/src/test/org/apache/lucene/analysis/ja/dict/UserDictionaryTest.java
 ##
 @@ -77,4 +78,19 @@ public void testRead() throws IOException {
 UserDictionary dictionary = TestJapaneseTokenizer.readDict();
 assertNotNull(dictionary);
   }
+
+  @Test(expected = RuntimeException.class)
 
 Review comment:
   I think you mean `assertThrows` that was introduced from JUnit 4.13
   
https://junit.org/junit4/javadoc/latest/org/junit/Assert.html#assertThrows(java.lang.String,%20java.lang.Class,%20org.junit.function.ThrowingRunnable)
   
   Lucene uses junit 4.12, so we cannot use it (Am I missing something?).


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

[JENKINS] Lucene-Solr-Tests-8.x - Build # 405 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/405/

All tests passed

Build Log:
[...truncated 12349 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:634: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:578: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:59: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build.xml:231: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:506:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:401:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2056:
 Error starting modern compiler

Total time: 83 minutes 35 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13688) Make the bin/solr export command to run one thread per shard

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906741#comment-16906741
 ] 

ASF subversion and git services commented on SOLR-13688:


Commit 8be67aa4c401800233f5f2f0b7431bccaeef1633 in lucene-solr's branch 
refs/heads/branch_8x from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8be67aa ]

SOLR-13688: compile error on java 8


> Make the bin/solr export command to run one thread per shard
> 
>
> Key: SOLR-13688
> URL: https://issues.apache.org/jira/browse/SOLR-13688
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.3
>
>
> This can be run in parallel with one dedicated thread for each shard and 
> (distrib=false) option
> this will be the only option



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906732#comment-16906732
 ] 

Mark Miller commented on SOLR-13452:


Okay, I've updated to trunk, got the dependencies checking tasks largely 
working on all the modules, and am still working through some other dep stuff.

Dev has moved to 
[https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5|https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5]

> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-13452:
---
Description: 
I took some things from the great work that Dat did in 
[https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
little further.

 

When working with gradle in sub modules directly, I recommend 
[https://github.com/dougborg/gdub]

This gradle branch uses the following plugin for version locking, version 
configuration and version consistency across modules: 
[https://github.com/palantir/gradle-consistent-versions]

 

https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5

  was:
I took some things from the great work that Dat did in 
[https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
little further.

 

When working with gradle in sub modules directly, I recommend 
[https://github.com/dougborg/gdub]

This gradle branch uses the following plugin for version locking, version 
configuration and version consistency across modules: 
[https://github.com/palantir/gradle-consistent-versions]

 

https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906721#comment-16906721
 ] 

ASF subversion and git services commented on SOLR-13452:


Commit c052e84aa6416e27c8842c2552334efacea214b8 in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c052e84 ]

SOLR-13452: Clean up exclude defs.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906727#comment-16906727
 ] 

ASF subversion and git services commented on SOLR-13452:


Commit 0436ab0f491c8bf9b9b7678d87dc21c8a598b45d in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0436ab0 ]

SOLR-13452: Add some comments, use the build cache by default.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906725#comment-16906725
 ] 

ASF subversion and git services commented on SOLR-13452:


Commit 107837293ba0aa40358f4571c9801add4a20e37c in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1078372 ]

SOLR-13452: Clean up debug code.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906722#comment-16906722
 ] 

ASF subversion and git services commented on SOLR-13452:


Commit 22baaee57fb945f4f47ea55833ea77eb456d58a2 in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=22baaee ]

SOLR-13452: More work on dependencies and related tasks.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906729#comment-16906729
 ] 

ASF subversion and git services commented on SOLR-13452:


Commit 1d7264dff79335655f9e8d8ceb09f71079a6a2ee in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1d7264d ]

SOLR-13452: Finish work on the dep checking tasks so that they work on each 
module and from top level.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906728#comment-16906728
 ] 

ASF subversion and git services commented on SOLR-13452:


Commit 4754bcd095cc575aba700b196ada40e323008fea in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4754bcd ]

SOLR-13452: Get merged up master working again.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906720#comment-16906720
 ] 

ASF subversion and git services commented on SOLR-13452:


Commit 3c81fce246765af0f2a0d3e93c9763e4bd16425b in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3c81fce ]

SOLR-13452: Updates needed after merging to latest master.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906726#comment-16906726
 ] 

ASF subversion and git services commented on SOLR-13452:


Commit 6fa2fac265e98a6563d7da25e2545ac28cf33205 in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6fa2fac ]

SOLR-13452: Move checks from constructor to execute.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906724#comment-16906724
 ] 

ASF subversion and git services commented on SOLR-13452:


Commit 9dad4b859fdbbceac78f4701b01fc05b40858027 in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9dad4b8 ]

SOLR-13452: Yet more work on dependencies and missingDependencies task.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906723#comment-16906723
 ] 

ASF subversion and git services commented on SOLR-13452:


Commit 46db519646d3b8a5abe9eac35e0ac23eabe01736 in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=46db519 ]

SOLR-13452: More work on dependencies and missingDependencies task.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-8.x-Windows (64bit/jdk-14-ea+9) - Build # 398 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/398/
Java: 64bit/jdk-14-ea+9 -XX:-UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 12360 lines...]
[javac] Compiling 1284 source files to 
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\classes\java
[javac] 
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\core\src\java\org\apache\solr\util\ExportTool.java:312:
 error: cannot infer type arguments for BiConsumer
[javac] private BiConsumer bic= new BiConsumer<>() {
[javac]   ^
[javac]   reason: '<>' with anonymous inner classes is not supported in 
-source 8
[javac] (use -source 9 or higher to enable '<>' with anonymous inner 
classes)
[javac]   where T,U are type-variables:
[javac] T extends Object declared in interface BiConsumer
[javac] U extends Object declared in interface BiConsumer
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\build.xml:634: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\build.xml:578: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\build.xml:59: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build.xml:231: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\common-build.xml:558: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\common-build.xml:506: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\common-build.xml:401: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\common-build.xml:558: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\common-build.xml:2056:
 Compile failed; see the compiler error output for details.

Total time: 24 minutes 36 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Solr-Artifacts-8.x - Build # 186 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-Artifacts-8.x/186/

No tests ran.

Build Log:
[...truncated 2515 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-8.x/solr/build.xml:506: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-8.x/solr/common-build.xml:414:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-8.x/lucene/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-8.x/lucene/common-build.xml:2056:
 Error starting modern compiler

Total time: 1 minute 13 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-8.x - Build # 404 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/404/

All tests passed

Build Log:
[...truncated 12348 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:634: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:578: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:59: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build.xml:231: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:506:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:401:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2056:
 Error starting modern compiler

Total time: 82 minutes 28 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-8.x-Linux (32bit/jdk1.8.0_201) - Build # 1012 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/1012/
Java: 32bit/jdk1.8.0_201 -server -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 12355 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:634: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:578: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:59: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build.xml:231: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:558: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:506: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:401: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/common-build.xml:558: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/common-build.xml:2056: 
Error starting modern compiler

Total time: 37 minutes 10 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] dsmiley commented on issue #633: LUCENE-8753 UniformSplit PostingsFormat

[GitBox]

dsmiley commented on issue #633: LUCENE-8753 UniformSplit PostingsFormat
URL: https://github.com/apache/lucene-solr/pull/633#issuecomment-521036009
 
 
   Moved to #828 so I am closing this.


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] dsmiley closed pull request #633: LUCENE-8753 UniformSplit PostingsFormat

[GitBox]

dsmiley closed pull request #633: LUCENE-8753 UniformSplit PostingsFormat
URL: https://github.com/apache/lucene-solr/pull/633
 
 
   


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] noblepaul commented on a change in pull request #825: SOLR-13677 All Metrics Gauges should be unregistered by the objects that registered them

[GitBox]

noblepaul commented on a change in pull request #825: SOLR-13677 All Metrics 
Gauges should be unregistered by the objects that registered them
URL: https://github.com/apache/lucene-solr/pull/825#discussion_r313628882
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java
 ##
 @@ -145,8 +145,14 @@ public void init(NamedList args) {
 
   }
 
+  protected MetricsInfo metricsInfo;
+
+
   @Override
   public void initializeMetrics(SolrMetricManager manager, String 
registryName, String tag, final String scope) {
+metricsInfo = new MetricsInfo(manager, registryName, 
getUniqueMetricTag(tag)) ;
+tag = metricsInfo.getTag();
 
 Review comment:
   Yeah, we should avoid passing this zillion different parameters . But the 
problem is it is too much of a change. However I'll try to do it


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] dsmiley commented on issue #824: LUCENE-8755: QuadPrefixTree robustness

[GitBox]

dsmiley commented on issue #824: LUCENE-8755: QuadPrefixTree robustness
URL: https://github.com/apache/lucene-solr/pull/824#issuecomment-521022106
 
 
   Any concerns/questions on the commit I added @chenkovsky ?
   
   BTW this is the first time I used a feature of GitHub that allows me (a 
member of this repo) to commit to the source branch of someone's PR.  Pretty 
cool for collaboration.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk-11.0.3) - Build # 271 - Still Failing!

[Chris Hostetter]

https://issues.apache.org/jira/browse/SOLR-13688

: Date: Tue, 13 Aug 2019 19:48:25 + (UTC)
: From: Policeman Jenkins Server 
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: [JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk-11.0.3) - Build # 271 -
: Still Failing!
: 
: Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/271/
: Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseSerialGC
: 
: All tests passed
: 
: Build Log:
: [...truncated 12279 lines...]
: [javac] Compiling 1284 source files to 
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build/solr-core/classes/java
: [javac] 
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/core/src/java/org/apache/solr/util/ExportTool.java:312:
 error: cannot infer type arguments for BiConsumer
: [javac] private BiConsumer bic= new BiConsumer<>() {
: [javac]   ^
: [javac]   reason: '<>' with anonymous inner classes is not supported in 
-source 8
: [javac] (use -source 9 or higher to enable '<>' with anonymous inner 
classes)
: [javac]   where T,U are type-variables:
: [javac] T extends Object declared in interface BiConsumer
: [javac] U extends Object declared in interface BiConsumer
: [javac] Note: Some input files use or override a deprecated API.
: [javac] Note: Recompile with -Xlint:deprecation for details.
: [javac] Note: Some input files use unchecked or unsafe operations.
: [javac] Note: Recompile with -Xlint:unchecked for details.
: [javac] 1 error
: 
: BUILD FAILED
: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/build.xml:634: The following 
error occurred while executing this line:
: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/build.xml:578: The following 
error occurred while executing this line:
: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/build.xml:59: The following 
error occurred while executing this line:
: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build.xml:231: The 
following error occurred while executing this line:
: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/common-build.xml:558: 
The following error occurred while executing this line:
: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/common-build.xml:506: 
The following error occurred while executing this line:
: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/common-build.xml:401: 
The following error occurred while executing this line:
: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/common-build.xml:558: 
The following error occurred while executing this line:
: /Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/common-build.xml:2056: 
Compile failed; see the compiler error output for details.
: 
: Total time: 30 minutes 40 seconds
: Build step 'Invoke Ant' marked build as failure
: Archiving artifacts
: Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
: [WARNINGS] Skipping publisher since build result is FAILURE
: Recording test results
: Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
: Email was triggered for: Failure - Any
: Sending email for trigger: Failure - Any
: Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
: Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
: Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
: Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
: Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
: Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
: 

-Hoss
http://www.lucidworks.com/

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Reopened] (SOLR-13688) Make the bin/solr export command to run one thread per shard

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man reopened SOLR-13688:
-

8x doesn't compile...

https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/271/
{noformat}
Build Log:
[...truncated 12279 lines...]
[javac] Compiling 1284 source files to 
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build/solr-core/classes/java
[javac] 
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/core/src/java/org/apache/solr/util/ExportTool.java:312:
 error: cannot infer type
arguments for BiConsumer
[javac] private BiConsumer bic= new BiConsumer<>() {
[javac]   ^
[javac]   reason: '<>' with anonymous inner classes is not supported in 
-source 8
[javac] (use -source 9 or higher to enable '<>' with anonymous inner 
classes)
[javac]   where T,U are type-variables:
[javac] T extends Object declared in interface BiConsumer
[javac] U extends Object declared in interface BiConsumer
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error


{noformat}

> Make the bin/solr export command to run one thread per shard
> 
>
> Key: SOLR-13688
> URL: https://issues.apache.org/jira/browse/SOLR-13688
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.3
>
>
> This can be run in parallel with one dedicated thread for each shard and 
> (distrib=false) option
> this will be the only option



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] noblepaul commented on a change in pull request #825: SOLR-13677 All Metrics Gauges should be unregistered by the objects that registered them

[GitBox]

noblepaul commented on a change in pull request #825: SOLR-13677 All Metrics 
Gauges should be unregistered by the objects that registered them
URL: https://github.com/apache/lucene-solr/pull/825#discussion_r313621446
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/metrics/SolrMetricProducer.java
 ##
 @@ -19,17 +19,58 @@
 /**
  * Used by objects that expose metrics through {@link SolrCoreMetricManager}.
  */
-public interface SolrMetricProducer {
+public interface SolrMetricProducer extends AutoCloseable {
+
+  /**
+   * Unique metric name is in the format of A/B/C
+   * A is the parent of B is the parent of C and so on.
+   * If object "B" is unregistered , C also must get unregistered.
+   * If object "A" is unregistered ,  B , C also must get unregistered.
+   *
+   * @param parentName
+   */
+  default String getUniqueMetricTag(String parentName) {
+String name = getClass().getSimpleName() + "@" + 
Integer.toHexString(hashCode());
+return parentName == null ?
+name :
+parentName + "/" + name;
+  }
+
+  default void close() throws Exception{
+
+  }
+
 
   /**
* Initializes metrics specific to this producer
-   * @param manager an instance of {@link SolrMetricManager}
+   *
+   * @param manager  an instance of {@link SolrMetricManager}
* @param registry registry name where metrics are registered
-   * @param tag a symbolic tag that represents this instance of the producer,
-   * or a group of related instances that have the same life-cycle. This tag is
-   * used when managing life-cycle of some metrics and is set when
-   * {@link #initializeMetrics(SolrMetricManager, String, String, String)} is 
called.
-   * @param scope scope of the metrics (eg. handler name) to separate metrics 
of
+   * @param tag  a symbolic tag that represents this instance of the 
producer,
+   * or a group of related instances that have the same 
life-cycle. This tag is
+   * used when managing life-cycle of some metrics and is set 
when
+   * {@link #initializeMetrics(SolrMetricManager, String, 
String, String)} is called.
+   * @param scopescope of the metrics (eg. handler name) to separate 
metrics of
*/
   void initializeMetrics(SolrMetricManager manager, String registry, String 
tag, String scope);
+
+  class MetricsInfo {
 
 Review comment:
   Well, it contains more information than just a tag. That's why I had to 
choose a name other than MetricsTag. The problem we have with Metrics framework 
is that every component that is a MetricsProducer is forced to be aware of all 
internals of MetricsFramework. We should minimize the no:of Objects one need to 
keep track of (ideally a single Object)


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

[JENKINS] Lucene-Solr-Tests-8.x - Build # 403 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/403/

All tests passed

Build Log:
[...truncated 12339 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:634: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:578: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:59: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build.xml:231: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:506:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:401:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2056:
 Error starting modern compiler

Total time: 79 minutes 57 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 180 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/180/

No tests ran.

Build Log:
[...truncated 25 lines...]
ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data
org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the 
server
svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data'
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119)
at 
org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at 
org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
... 4 more
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)

[JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 264 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/264/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 12276 lines...]
BUILD FAILED
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/build.xml:634: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/build.xml:578: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/build.xml:59: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/build.xml:231: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/common-build.xml:558:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/common-build.xml:506:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/common-build.xml:401:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/lucene/common-build.xml:558:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/lucene/common-build.xml:2056:
 Error starting modern compiler

Total time: 18 minutes 40 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13693) Use strongly-typed setters for cache parameters

[Lucene/Solr QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906573#comment-16906573
 ] 

Lucene/Solr QA commented on SOLR-13693:
---

| (/) *{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 3 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
50s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  3m 
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  3m 
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  3m 36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  3m 36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  3m 36s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 51m 
37s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 60m 26s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13693 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12977509/SOLR-13693.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 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 / 9e60473 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/528/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/528/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Use strongly-typed setters for cache parameters
> ---
>
> Key: SOLR-13693
> URL: https://issues.apache.org/jira/browse/SOLR-13693
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13693.patch
>
>
> SOLR-13558 added ability to modify cache parameters on the fly. It uses an 
> API similar to the originally proposed API in SOLR-13579. After several 
> iterations of that patch it became clear that the originally proposed 
> weakly-typed API should be replaced with a strongly-typed one.
> Since it's a new API in 8.3 there are no back-compat considerations.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk-11.0.3) - Build # 271 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/271/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 12279 lines...]
[javac] Compiling 1284 source files to 
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build/solr-core/classes/java
[javac] 
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/core/src/java/org/apache/solr/util/ExportTool.java:312:
 error: cannot infer type arguments for BiConsumer
[javac] private BiConsumer bic= new BiConsumer<>() {
[javac]   ^
[javac]   reason: '<>' with anonymous inner classes is not supported in 
-source 8
[javac] (use -source 9 or higher to enable '<>' with anonymous inner 
classes)
[javac]   where T,U are type-variables:
[javac] T extends Object declared in interface BiConsumer
[javac] U extends Object declared in interface BiConsumer
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/build.xml:634: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/build.xml:578: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/build.xml:59: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build.xml:231: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/common-build.xml:558: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/common-build.xml:506: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/common-build.xml:401: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/common-build.xml:558: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/common-build.xml:2056: 
Compile failed; see the compiler error output for details.

Total time: 30 minutes 40 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

-
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/jdk1.8.0_201) - Build # 1011 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/1011/
Java: 64bit/jdk1.8.0_201 -XX:-UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 12346 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:634: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:578: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:59: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build.xml:231: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:558: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:506: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:401: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/common-build.xml:558: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/common-build.xml:2056: 
Error starting modern compiler

Total time: 35 minutes 50 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-8.x - Build # 402 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/402/

All tests passed

Build Log:
[...truncated 12320 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:634: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:578: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:59: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build.xml:231: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:506:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:401:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2056:
 Error starting modern compiler

Total time: 40 minutes 53 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13694) IndexSizeEstimator NullPointerException

[Andrzej Bialecki (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrzej Bialecki  updated SOLR-13694:
-
Attachment: SOLR-13694.patch

> IndexSizeEstimator NullPointerException
> ---
>
> Key: SOLR-13694
> URL: https://issues.apache.org/jira/browse/SOLR-13694
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13694.patch
>
>
> Jenkins found a reproducible seed for trigging an NPE in 
> IndexSizeEstimatorTest
> Based on a little experimental tracing i did, this might be a real bug in 
> IndexSizeEstimator? ... it's calling close on StoredFieldsReader instances it 
> gets from the CodecReader -- but AFAICT from the docs/code i'm not certain if 
> it should be doing this.  It appears the expectation is that this is direct 
> access to the internal state, that will automatically be closed when the 
> CodecReader is closed.
> ie: IndexSizeEstimator is closing StoredFieldsReader pre-maturely, causing it 
> to be unusbale on the next iteration.
> (I didn't dig in far enough to guess if there are other places in the 
> IndexSizeEstimator code that are closing CodecReader internals prematurely as 
> well, or just in this situation ... it's also not clear if this only causes 
> failures because this seed uses SimpleTextCodec, and other codecs are more 
> forgiving -- or if something else about the index(es) generated for this seed 
> are what cause the problem to manifest)
> http://fucit.org/solr-jenkins-reports/job-data/apache/Lucene-Solr-NightlyTests-master/1928
> {noformat}
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ git rev-parse HEAD
> 0291db44bc8e092f7cb2f577f0ac8ab6fa6a5fd7
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true  -Dtests.locale=eo -Dtests.timezone=Atlantic/Madeira 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ...
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=eo 
> -Dtests.timezone=Atlantic/Madeira -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.88s | IndexSizeEstimatorTest.testEstimator <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([23F60434E13D8FD4:EC2B6B666D451E64]:0)
>[junit4]>at 
> org.apache.lucene.codecs.simpletext.SimpleTextStoredFieldsReader.visitDocument(SimpleTextStoredFieldsReader.java:109)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimateStoredFields(IndexSizeEstimator.java:513)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimate(IndexSizeEstimator.java:198)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimatorTest.testEstimator(IndexSizeEstimatorTest.java:117)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>at 
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>[junit4]>at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception

[Lucene/Solr QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906529#comment-16906529
 ] 

Lucene/Solr QA commented on SOLR-13240:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
7s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 52s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  9m 
23s{color} | {color:green} solrj in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 17m 57s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13240 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12977498/SOLR-13240.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 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 / 9e60473 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/527/testReport/ |
| modules | C: solr/solrj U: solr/solrj |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/527/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
>  Issue Type: Bug
>  Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, 
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, 
> solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it 
> moved a few replicas:
> {
>   "responseHeader":{
> "status":500,
> "QTime":40220},
>   "Operation utilizenode caused 
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
>  Comparison method violates its general contract!",
>   "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
>   "error":{
> "metadata":[
>   "error-class","org.apache.solr.common.SolrException",
>   "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates 
> its general contract!\n\tat 
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>  
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>  

[jira] [Comment Edited] (SOLR-13694) IndexSizeEstimator NullPointerException

[Andrzej Bialecki (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906494#comment-16906494
 ] 

Andrzej Bialecki  edited comment on SOLR-13694 at 8/13/19 6:41 PM:
---

Indeed, it's a bug in {{IndexSizeEstimator}} - the {{StoredFieldsReader}} is 
not supposed to be closed other than from within CodecReader.close(). I'll fix 
it in a moment.

(SimpleTextCodec / SimpleTextStoreFieldsReader doesn't override 
getMergeInstance(), which means it returns itself, unlike all other codecs 
which return a clone).


was (Author: ab):
Indeed, it's a bug in {{IndexSizeEstimator}} - the {{StoredFieldsReader}} is 
not supposed to be closed other than from within CodecReader.close(). I'll fix 
it in a moment.

> IndexSizeEstimator NullPointerException
> ---
>
> Key: SOLR-13694
> URL: https://issues.apache.org/jira/browse/SOLR-13694
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
>
> Jenkins found a reproducible seed for trigging an NPE in 
> IndexSizeEstimatorTest
> Based on a little experimental tracing i did, this might be a real bug in 
> IndexSizeEstimator? ... it's calling close on StoredFieldsReader instances it 
> gets from the CodecReader -- but AFAICT from the docs/code i'm not certain if 
> it should be doing this.  It appears the expectation is that this is direct 
> access to the internal state, that will automatically be closed when the 
> CodecReader is closed.
> ie: IndexSizeEstimator is closing StoredFieldsReader pre-maturely, causing it 
> to be unusbale on the next iteration.
> (I didn't dig in far enough to guess if there are other places in the 
> IndexSizeEstimator code that are closing CodecReader internals prematurely as 
> well, or just in this situation ... it's also not clear if this only causes 
> failures because this seed uses SimpleTextCodec, and other codecs are more 
> forgiving -- or if something else about the index(es) generated for this seed 
> are what cause the problem to manifest)
> http://fucit.org/solr-jenkins-reports/job-data/apache/Lucene-Solr-NightlyTests-master/1928
> {noformat}
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ git rev-parse HEAD
> 0291db44bc8e092f7cb2f577f0ac8ab6fa6a5fd7
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true  -Dtests.locale=eo -Dtests.timezone=Atlantic/Madeira 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ...
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=eo 
> -Dtests.timezone=Atlantic/Madeira -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.88s | IndexSizeEstimatorTest.testEstimator <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([23F60434E13D8FD4:EC2B6B666D451E64]:0)
>[junit4]>at 
> org.apache.lucene.codecs.simpletext.SimpleTextStoredFieldsReader.visitDocument(SimpleTextStoredFieldsReader.java:109)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimateStoredFields(IndexSizeEstimator.java:513)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimate(IndexSizeEstimator.java:198)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimatorTest.testEstimator(IndexSizeEstimatorTest.java:117)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>at 
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>[junit4]>at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete

[Simon Willnauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906502#comment-16906502
 ] 

Simon Willnauer commented on LUCENE-8369:
-

+1 for option 1 above as well. Thanks [~nknize]

> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple 
> utilities that aren't used by anything in the entire codebase -- 
> GeoRelationUtils, and MortonEncoder.  Perhaps it should have been removed 
> earlier in LUCENE-7664 which was the removal of GeoPointField which was 
> essentially why the module existed.  Better late than never.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13694) IndexSizeEstimator NullPointerException

[Andrzej Bialecki (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906494#comment-16906494
 ] 

Andrzej Bialecki  commented on SOLR-13694:
--

Indeed, it's a bug in {{IndexSizeEstimator}} - the {{StoredFieldsReader}} is 
not supposed to be closed other than from within CodecReader.close(). I'll fix 
it in a moment.

> IndexSizeEstimator NullPointerException
> ---
>
> Key: SOLR-13694
> URL: https://issues.apache.org/jira/browse/SOLR-13694
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
>
> Jenkins found a reproducible seed for trigging an NPE in 
> IndexSizeEstimatorTest
> Based on a little experimental tracing i did, this might be a real bug in 
> IndexSizeEstimator? ... it's calling close on StoredFieldsReader instances it 
> gets from the CodecReader -- but AFAICT from the docs/code i'm not certain if 
> it should be doing this.  It appears the expectation is that this is direct 
> access to the internal state, that will automatically be closed when the 
> CodecReader is closed.
> ie: IndexSizeEstimator is closing StoredFieldsReader pre-maturely, causing it 
> to be unusbale on the next iteration.
> (I didn't dig in far enough to guess if there are other places in the 
> IndexSizeEstimator code that are closing CodecReader internals prematurely as 
> well, or just in this situation ... it's also not clear if this only causes 
> failures because this seed uses SimpleTextCodec, and other codecs are more 
> forgiving -- or if something else about the index(es) generated for this seed 
> are what cause the problem to manifest)
> http://fucit.org/solr-jenkins-reports/job-data/apache/Lucene-Solr-NightlyTests-master/1928
> {noformat}
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ git rev-parse HEAD
> 0291db44bc8e092f7cb2f577f0ac8ab6fa6a5fd7
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true  -Dtests.locale=eo -Dtests.timezone=Atlantic/Madeira 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ...
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=eo 
> -Dtests.timezone=Atlantic/Madeira -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.88s | IndexSizeEstimatorTest.testEstimator <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([23F60434E13D8FD4:EC2B6B666D451E64]:0)
>[junit4]>at 
> org.apache.lucene.codecs.simpletext.SimpleTextStoredFieldsReader.visitDocument(SimpleTextStoredFieldsReader.java:109)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimateStoredFields(IndexSizeEstimator.java:513)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimate(IndexSizeEstimator.java:198)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimatorTest.testEstimator(IndexSizeEstimatorTest.java:117)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>at 
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>[junit4]>at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-13694) IndexSizeEstimator NullPointerException

[Hoss Man (JIRA)]

Hoss Man created SOLR-13694:
---

 Summary: IndexSizeEstimator NullPointerException
 Key: SOLR-13694
 URL: https://issues.apache.org/jira/browse/SOLR-13694
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Andrzej Bialecki 



Jenkins found a reproducible seed for trigging an NPE in IndexSizeEstimatorTest

Based on a little experimental tracing i did, this might be a real bug in 
IndexSizeEstimator? ... it's calling close on StoredFieldsReader instances it 
gets from the CodecReader -- but AFAICT from the docs/code i'm not certain if 
it should be doing this.  It appears the expectation is that this is direct 
access to the internal state, that will automatically be closed when the 
CodecReader is closed.

ie: IndexSizeEstimator is closing StoredFieldsReader pre-maturely, causing it 
to be unusbale on the next iteration.

(I didn't dig in far enough to guess if there are other places in the 
IndexSizeEstimator code that are closing CodecReader internals prematurely as 
well, or just in this situation ... it's also not clear if this only causes 
failures because this seed uses SimpleTextCodec, and other codecs are more 
forgiving -- or if something else about the index(es) generated for this seed 
are what cause the problem to manifest)

http://fucit.org/solr-jenkins-reports/job-data/apache/Lucene-Solr-NightlyTests-master/1928
{noformat}
hossman@tray:~/lucene/dev/solr/core [j11] [master] $ git rev-parse HEAD
0291db44bc8e092f7cb2f577f0ac8ab6fa6a5fd7
hossman@tray:~/lucene/dev/solr/core [j11] [master] $ ant test  
-Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
-Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true  -Dtests.locale=eo -Dtests.timezone=Atlantic/Madeira 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
...
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
-Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=eo 
-Dtests.timezone=Atlantic/Madeira -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.88s | IndexSizeEstimatorTest.testEstimator <<<
   [junit4]> Throwable #1: java.lang.NullPointerException
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([23F60434E13D8FD4:EC2B6B666D451E64]:0)
   [junit4]>at 
org.apache.lucene.codecs.simpletext.SimpleTextStoredFieldsReader.visitDocument(SimpleTextStoredFieldsReader.java:109)
   [junit4]>at 
org.apache.solr.handler.admin.IndexSizeEstimator.estimateStoredFields(IndexSizeEstimator.java:513)
   [junit4]>at 
org.apache.solr.handler.admin.IndexSizeEstimator.estimate(IndexSizeEstimator.java:198)
   [junit4]>at 
org.apache.solr.handler.admin.IndexSizeEstimatorTest.testEstimator(IndexSizeEstimatorTest.java:117)
   [junit4]>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   [junit4]>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   [junit4]>at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]>at 
java.base/java.lang.reflect.Method.invoke(Method.java:566)
   [junit4]>at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] MarcusSorealheis commented on issue #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

MarcusSorealheis commented on issue #805: SOLR-13649 change the default 
behavior of the basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#issuecomment-520925774
 
 
   > My comment about ERROR above was related to the special case where people 
initialize security.json without any users, like `"authentication": 
{"class":"solr.BasicAuthPlugin"}`. In this case today nothing will happen since 
blockUnknown=false, but when we change the default, the entire cluster is 
completely locked for everyone. So my question was whether to allow such a 
config at all, or to allow configs with no users only if blockUnknown is 
explicitly set to false.
   
   Makes perfect sense.


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

[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk1.8.0_201) - Build # 397 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/397/
Java: 64bit/jdk1.8.0_201 -XX:+UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 12353 lines...]
BUILD FAILED
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\build.xml:634: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\build.xml:578: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\build.xml:59: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build.xml:231: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\common-build.xml:558: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\common-build.xml:506: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\common-build.xml:401: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\common-build.xml:558: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\lucene\common-build.xml:2056:
 Error starting modern compiler

Total time: 23 minutes 57 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1420 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1420/

No tests ran.

Build Log:
[...truncated 24456 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2593 links (2119 relative) to 3411 anchors in 259 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-9.0.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

[jira] [Updated] (SOLR-13693) Use strongly-typed setters for cache parameters

[Andrzej Bialecki (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrzej Bialecki  updated SOLR-13693:
-
Status: Patch Available  (was: Open)

> Use strongly-typed setters for cache parameters
> ---
>
> Key: SOLR-13693
> URL: https://issues.apache.org/jira/browse/SOLR-13693
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13693.patch
>
>
> SOLR-13558 added ability to modify cache parameters on the fly. It uses an 
> API similar to the originally proposed API in SOLR-13579. After several 
> iterations of that patch it became clear that the originally proposed 
> weakly-typed API should be replaced with a strongly-typed one.
> Since it's a new API in 8.3 there are no back-compat considerations.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
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-12.0.1) - Build # 1010 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/1010/
Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 12353 lines...]
[javac] Compiling 1284 source files to 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build/solr-core/classes/java
[javac] 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/core/src/java/org/apache/solr/util/ExportTool.java:312:
 error: cannot infer type arguments for BiConsumer
[javac] private BiConsumer bic= new BiConsumer<>() {
[javac]   ^
[javac]   reason: '<>' with anonymous inner classes is not supported in 
-source 8
[javac] (use -source 9 or higher to enable '<>' with anonymous inner 
classes)
[javac]   where T,U are type-variables:
[javac] T extends Object declared in interface BiConsumer
[javac] U extends Object declared in interface BiConsumer
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:634: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:578: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:59: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build.xml:231: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:558: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:506: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:401: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/common-build.xml:558: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/common-build.xml:2056: 
Compile failed; see the compiler error output for details.

Total time: 36 minutes 35 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13693) Use strongly-typed setters for cache parameters

[Andrzej Bialecki (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrzej Bialecki  updated SOLR-13693:
-
Attachment: SOLR-13693.patch

> Use strongly-typed setters for cache parameters
> ---
>
> Key: SOLR-13693
> URL: https://issues.apache.org/jira/browse/SOLR-13693
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13693.patch
>
>
> SOLR-13558 added ability to modify cache parameters on the fly. It uses an 
> API similar to the originally proposed API in SOLR-13579. After several 
> iterations of that patch it became clear that the originally proposed 
> weakly-typed API should be replaced with a strongly-typed one.
> Since it's a new API in 8.3 there are no back-compat considerations.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-MAVEN] Lucene-Solr-Maven-8.x #185: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-8.x/185/

No tests ran.

Build Log:
[...truncated 11388 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/build.xml:673: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/build.xml:223: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/solr/common-build.xml:66:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/solr/common-build.xml:61:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/solr/build.xml:506: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/solr/common-build.xml:414:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/lucene/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/lucene/common-build.xml:2056:
 Error starting modern compiler

Total time: 8 minutes 33 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-8.x - Build # 401 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/401/

All tests passed

Build Log:
[...truncated 12339 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:634: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:578: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:59: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build.xml:231: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:506:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:401:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2056:
 Error starting modern compiler

Total time: 79 minutes 38 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception

[Christine Poerschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906293#comment-16906293
 ] 

Christine Poerschke commented on SOLR-13240:


Thanks [~goodman] revising the patch, this time it passed QA (yay!) and I've 
gone ahead and pulled out two small separate bits from it into the commit above 
(to potentially make for an easier diff on the remaining changes).

So as a next step then I was trying to better understand the {{TestPolicy}} 
changes:
 * for TestPolicy.testReplicaCountSuggestions just a comment seems sufficient
 * for TestPolicy.testNodeLostMultipleReplica it was a bit tricky to understand 
first of all what the existing test actually does; with that in mind the 
just-attached patch includes two small refactors to surface the sequential 
nature of part of the test – would appreciate any thoughts on that.

With the small refactor in place we can more easily see that two sub-tests are 
being changed:
 * "lets change the policy such that all replicas that were on node1 can now 
fit on node2"
 * "now lets change the policy such that a node can have 2 shard2 replicas"

Now to the tricky bit. My interpretion of the revised test expectations is that 
now then the "a node can have 2 shardX replicas" condition is no longer being 
met i.e. previously r3 and r5 were expected to be on node2 but now r3 and r5 
are expected on different nodes. So whilst technically speaking the test 
passes, the coverage it intended to provide has been lost and so further 
adjustments to that sub-test might be needed to preserve the intended coverage. 
What do you think?

> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
>  Issue Type: Bug
>  Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, 
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, 
> solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it 
> moved a few replicas:
> {
>   "responseHeader":{
> "status":500,
> "QTime":40220},
>   "Operation utilizenode caused 
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
>  Comparison method violates its general contract!",
>   "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
>   "error":{
> "metadata":[
>   "error-class","org.apache.solr.common.SolrException",
>   "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates 
> its general contract!\n\tat 
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>  
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>  
> 

[jira] [Updated] (SOLR-13240) UTILIZENODE action results in an exception

[Christine Poerschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Poerschke updated SOLR-13240:
---
Attachment: SOLR-13240.patch

> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
>  Issue Type: Bug
>  Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, 
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, 
> solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it 
> moved a few replicas:
> {
>   "responseHeader":{
> "status":500,
> "QTime":40220},
>   "Operation utilizenode caused 
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
>  Comparison method violates its general contract!",
>   "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
>   "error":{
> "metadata":[
>   "error-class","org.apache.solr.common.SolrException",
>   "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates 
> its general contract!\n\tat 
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>  
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>  
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
>  org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat 
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>  
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>  
> 

[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906272#comment-16906272
 ] 

ASF subversion and git services commented on SOLR-13240:


Commit 4689fb8642df95eb4afecc62e7b8c97d6a63f051 in lucene-solr's branch 
refs/heads/branch_8x from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4689fb8 ]

SOLR-13240: make operation-not-null checks consistent in 
TestPolicy.testNodeLostMultipleReplica
(Richard Goodman via Christine Poerschke)


> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
>  Issue Type: Bug
>  Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, 
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it 
> moved a few replicas:
> {
>   "responseHeader":{
> "status":500,
> "QTime":40220},
>   "Operation utilizenode caused 
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
>  Comparison method violates its general contract!",
>   "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
>   "error":{
> "metadata":[
>   "error-class","org.apache.solr.common.SolrException",
>   "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates 
> its general contract!\n\tat 
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>  
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>  
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
>  

[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906268#comment-16906268
 ] 

ASF subversion and git services commented on SOLR-13240:


Commit 9e6047331b47a683b340d96fdcd00ca75e33e20c in lucene-solr's branch 
refs/heads/master from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9e60473 ]

SOLR-13240: make operation-not-null checks consistent in 
TestPolicy.testNodeLostMultipleReplica
(Richard Goodman via Christine Poerschke)


> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
>  Issue Type: Bug
>  Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, 
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it 
> moved a few replicas:
> {
>   "responseHeader":{
> "status":500,
> "QTime":40220},
>   "Operation utilizenode caused 
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
>  Comparison method violates its general contract!",
>   "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
>   "error":{
> "metadata":[
>   "error-class","org.apache.solr.common.SolrException",
>   "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates 
> its general contract!\n\tat 
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>  
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>  
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
>  

[JENKINS] Lucene-Solr-Tests-8.x - Build # 400 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/400/

All tests passed

Build Log:
[...truncated 12337 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:634: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:578: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:59: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build.xml:231: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:506:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:401:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2056:
 Error starting modern compiler

Total time: 79 minutes 49 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8753) New PostingFormat - UniformSplit

[Bruno Roustant (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906219#comment-16906219
 ] 

Bruno Roustant commented on LUCENE-8753:


New [PR 828|https://github.com/apache/lucene-solr/pull/828] to have this 
PostingsFormat inside codecs/uniformsplit with no code elsewhere. I added 
package javadoc and lucene.experimental annotation.

> New PostingFormat - UniformSplit
> 
>
> Key: LUCENE-8753
> URL: https://issues.apache.org/jira/browse/LUCENE-8753
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/codecs
>Affects Versions: 8.0
>Reporter: Bruno Roustant
>Assignee: David Smiley
>Priority: Major
> Attachments: Uniform Split Technique.pdf, luceneutil.benchmark.txt
>
>  Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> This is a proposal to add a new PostingsFormat called "UniformSplit" with 4 
> objectives:
>  - Clear design and simple code.
>  - Easily extensible, for both the logic and the index format.
>  - Light memory usage with a very compact FST.
>  - Focus on efficient TermQuery, PhraseQuery and PrefixQuery performance.
> (the pdf attached explains visually the technique in more details)
>  The principle is to split the list of terms into blocks and use a FST to 
> access the block, but not as a prefix trie, rather with a seek-floor pattern. 
> For the selection of the blocks, there is a target average block size (number 
> of terms), with an allowed delta variation (10%) to compare the terms and 
> select the one with the minimal distinguishing prefix.
>  There are also several optimizations inside the block to make it more 
> compact and speed up the loading/scanning.
> The performance obtained is interesting with the luceneutil benchmark, 
> comparing UniformSplit with BlockTree. Find it in the first comment and also 
> attached for better formatting.
> Although the precise percentages vary between runs, three main points:
>  - TermQuery and PhraseQuery are improved.
>  - PrefixQuery and WildcardQuery are ok.
>  - Fuzzy queries are clearly less performant, because BlockTree is so 
> optimized for them.
> Compared to BlockTree, FST size is reduced by 15%, and segment writing time 
> is reduced by 20%. So this PostingsFormat scales to lots of docs, as 
> BlockTree.
> This initial version passes all Lucene tests. Use “ant test 
> -Dtests.codec=UniformSplitTesting” to test with this PostingsFormat.
> Subjectively, we think we have fulfilled our goal of code simplicity. And we 
> have already exercised this PostingsFormat extensibility to create a 
> different flavor for our own use-case.
> Contributors: Juan Camilo Rodriguez Duran, Bruno Roustant, David Smiley



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] magibney commented on a change in pull request #677: SOLR-13257: support for stable replica routing preferences

[GitBox]

magibney commented on a change in pull request #677: SOLR-13257: support for 
stable replica routing preferences
URL: https://github.com/apache/lucene-solr/pull/677#discussion_r313402997
 
 

 ##
 File path: 
solr/core/src/java/org/apache/solr/handler/component/HttpShardHandlerFactory.java
 ##
 @@ -230,7 +288,23 @@ public void init(PluginInfo info) {
 this.accessPolicy = getParameter(args, INIT_FAIRNESS_POLICY, 
accessPolicy,sb);
 this.whitelistHostChecker = new WhitelistHostChecker(args == null? null: 
(String) args.get(INIT_SHARDS_WHITELIST), !getDisableShardsWhitelist());
 log.info("Host whitelist initialized: {}", this.whitelistHostChecker);
-
+
+this.httpListenerFactory = new 
InstrumentedHttpListenerFactory(this.metricNameStrategy);
+int connectionTimeout = getParameter(args, 
HttpClientUtil.PROP_CONNECTION_TIMEOUT,
+HttpClientUtil.DEFAULT_CONNECT_TIMEOUT, sb);
+int maxConnectionsPerHost = getParameter(args, 
HttpClientUtil.PROP_MAX_CONNECTIONS_PER_HOST,
+HttpClientUtil.DEFAULT_MAXCONNECTIONSPERHOST, sb);
+int soTimeout = getParameter(args, HttpClientUtil.PROP_SO_TIMEOUT,
+HttpClientUtil.DEFAULT_SO_TIMEOUT, sb);
+
+this.defaultClient = new Http2SolrClient.Builder()
+.connectionTimeout(connectionTimeout)
+.idleTimeout(soTimeout)
+.maxConnectionsPerHost(maxConnectionsPerHost).build();
+this.defaultClient.addListenerFactory(this.httpListenerFactory);
+this.loadbalancer = new LBHttp2SolrClient(defaultClient);
+initReplicaListTransformers(getParameter(args, "replicaRouting", null, 
sb));
+
 log.debug("created with {}",sb);
 
 Review comment:
   Yes, this would definitely be better. There's no reason for the "created" 
logging statement to be in the middle of the method, and in fact its being 
there initially is what nearly caused me to bypass it with the additions in 
this patch! Just pushed a commit to address this, thanks!


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] bruno-roustant opened a new pull request #828: LUCENE-8753: UniformSplitPostingsFormat

[GitBox]

bruno-roustant opened a new pull request #828: LUCENE-8753: 
UniformSplitPostingsFormat
URL: https://github.com/apache/lucene-solr/pull/828
 
 
   Follow up of PR#633 https://github.com/apache/lucene-solr/pull/633
   
   Moves DeltaBaseTermStateSerializer inside uniformsplit package.
   Adds lucene.experimental annotation to all classes.
   Adds package javadoc.


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

[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk1.8.0_201) - Build # 1009 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/1009/
Java: 64bit/jdk1.8.0_201 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 12354 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:634: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:578: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:59: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build.xml:231: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:558: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:506: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:401: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/common-build.xml:558: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/common-build.xml:2056: 
Error starting modern compiler

Total time: 36 minutes 2 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12638) Support atomic updates of nested/child documents for nested-enabled schema

[mosh (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906206#comment-16906206
 ] 

mosh commented on SOLR-12638:
-

{quote}_root_ must be set either as stored (stored="true") or doc values 
(docValues="true") to enable atomic updates of nested documents.{quote}
It currently states so in the ref guide, just under the _root_ field definition.

> Support atomic updates of nested/child documents for nested-enabled schema
> --
>
> Key: SOLR-12638
> URL: https://issues.apache.org/jira/browse/SOLR-12638
> Project: Solr
>  Issue Type: Sub-task
>Reporter: mosh
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-12638-delete-old-block-no-commit.patch, 
> SOLR-12638-nocommit.patch, SOLR-12638.patch, SOLR-12638.patch
>
>  Time Spent: 17h 10m
>  Remaining Estimate: 0h
>
> I have been toying with the thought of using this transformer in conjunction 
> with NestedUpdateProcessor and AtomicUpdate to allow SOLR to completely 
> re-index the entire nested structure. This is just a thought, I am still 
> thinking about implementation details. Hopefully I will be able to post a 
> more concrete proposal soon.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled

[Colvin Cowie (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906207#comment-16906207
 ] 

Colvin Cowie commented on SOLR-13510:
-

Hello. Looking at the changes.txt in the 8.2 release, 
[http://lucene.apache.org/core/8_2_0/changes/Changes.html#v8.2.0.bug_fixes] I 
don't see this issue referenced.
I expect because of this
{noformat}
Commit bd3cc0b6a18d9583d22ee0f8f997e411036f6220 in lucene-solr's branch 
refs/heads/master from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bd3cc0b ]

SOLR-13510: Move entry of CHANGES.txt to 8.1.2{noformat}
I suspect it's too late to do anything about it, and as long the fix is in the 
build itself, that's all that really matters.

> Intermittent 401's for internode requests with basicauth enabled
> 
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
>  Issue Type: Bug
>  Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2, 8.1.2
>
> Attachments: SOLR-13510.patch
>
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
>   "q":"*:*",
>   "_":"1559474550365"}},
>   "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
>  require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json 
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well.  Other auth issues (SOLR-13472) look 
> like they're impacted by the topography of the collection and cluster.  But 
> this doesn't seem affected by that at all (401's occur on inter-node requests 
> regardless of the recipient of the initial request, and even when all nodes 
> have a shard replica).



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 263 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/263/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 12278 lines...]
BUILD FAILED
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/build.xml:634: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/build.xml:578: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/build.xml:59: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/build.xml:231: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/common-build.xml:558:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/common-build.xml:506:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/common-build.xml:401:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/lucene/common-build.xml:558:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/lucene/common-build.xml:2056:
 Error starting modern compiler

Total time: 26 minutes 27 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] bruno-roustant commented on a change in pull request #633: LUCENE-8753 UniformSplit PostingsFormat

[GitBox]

bruno-roustant commented on a change in pull request #633: LUCENE-8753 
UniformSplit PostingsFormat
URL: https://github.com/apache/lucene-solr/pull/633#discussion_r313398353
 
 

 ##
 File path: 
lucene/codecs/src/java/org/apache/lucene/codecs/uniformsplit/BlockReader.java
 ##
 @@ -0,0 +1,535 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.codecs.uniformsplit;
+
+import java.io.IOException;
+import java.util.function.Supplier;
+
+import org.apache.lucene.codecs.BlockTermState;
+import org.apache.lucene.codecs.PostingsReaderBase;
+import org.apache.lucene.codecs.lucene50.DeltaBaseTermStateSerializer;
+import org.apache.lucene.index.BaseTermsEnum;
+import org.apache.lucene.index.ImpactsEnum;
+import org.apache.lucene.index.PostingsEnum;
+import org.apache.lucene.index.TermState;
+import org.apache.lucene.index.TermsEnum;
+import org.apache.lucene.store.ByteArrayDataInput;
+import org.apache.lucene.store.IndexInput;
+import org.apache.lucene.util.Accountable;
+import org.apache.lucene.util.ArrayUtil;
+import org.apache.lucene.util.BytesRef;
+import org.apache.lucene.util.BytesRefBuilder;
+import org.apache.lucene.util.RamUsageEstimator;
+
+/**
+ * Seeks the block corresponding to a given term, read the block bytes, and
+ * scans the block terms.
+ * 
+ * Reads fully the block in {@link #blockReadBuffer}. Then scans the block
+ * terms in memory. The details region is lazily decoded with {@link 
#termStatesReadBuffer}
+ * which shares the same byte array with {@link #blockReadBuffer}.
+ * See {@link BlockWriter} and {@link BlockLine} for the block format.
+ */
+public class BlockReader extends BaseTermsEnum implements Accountable {
+
+  private static final long BASE_RAM_USAGE = 
RamUsageEstimator.shallowSizeOfInstance(BlockReader.class)
+  + RamUsageEstimator.shallowSizeOfInstance(IndexInput .class)
+  +RamUsageEstimator.shallowSizeOfInstance(ByteArrayDataInput .class)*2;
+
+  /**
+   * {@link IndexInput} on the {@link 
UniformSplitPostingsFormat#TERMS_BLOCKS_EXTENSION block file}.
+   */
+  protected IndexInput blockInput;
+  protected final PostingsReaderBase postingsReader;
+  protected final FieldMetadata fieldMetadata;
+  protected final BlockDecoder blockDecoder;
+
+  protected BlockLine.Serializer blockLineReader;
+  /**
+   * In-memory read buffer for the current block.
+   */
+  protected ByteArrayDataInput blockReadBuffer;
+  /**
+   * In-memory read buffer for the details region of the current block.
+   * It shares the same byte array as {@link #blockReadBuffer}, with a
+   * different position.
+   */
+  protected ByteArrayDataInput termStatesReadBuffer;
+  protected DeltaBaseTermStateSerializer termStateSerializer;
+
+  /**
+   * {@link IndexDictionary.Browser} supplier for lazy loading.
+   */
+  protected final Supplier dictionaryBrowserSupplier;
+  /**
+   * Holds the {@link IndexDictionary.Browser} once loaded.
+   */
+  protected IndexDictionary.Browser dictionaryBrowser;
+
+  /**
+   * Current block start file pointer, absolute in the
+   * {@link UniformSplitPostingsFormat#TERMS_BLOCKS_EXTENSION block file}.
+   */
+  protected long blockStartFP;
+  /**
+   * Current block header.
+   */
+  protected BlockHeader blockHeader;
+  /**
+   * Current block line.
+   */
+  protected BlockLine blockLine;
+  /**
+   * Current block line details.
+   */
+  protected BlockTermState termState;
+  /**
+   * Offset of the start of the first line of the current block (just after 
the header), relative to the block start.
+   */
+  protected int blockFirstLineStart;
+  /**
+   * Current line index in the block.
+   */
+  protected int lineIndexInBlock;
+  /**
+   * Whether the current {@link TermState} has been forced with a call to
+   * {@link #seekExact(BytesRef, TermState)}.
+   *
+   * @see #forcedTerm
+   */
+  protected boolean termStateForced;
+  /**
+   * Set when {@link #seekExact(BytesRef, TermState)} is called.
+   * 
+   * This optimizes the use-case when the caller calls first {@link 
#seekExact(BytesRef, TermState)}
+   * and then {@link #postings(PostingsEnum, int)}. In this case we don't 
access
+   * the terms block file (we don't seek) but directly the postings file 

[JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk1.8.0) - Build # 270 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/270/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 12272 lines...]
BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/build.xml:634: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/build.xml:578: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/build.xml:59: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build.xml:231: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/common-build.xml:558: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/common-build.xml:506: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/common-build.xml:401: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/common-build.xml:558: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/common-build.xml:2056: 
Error starting modern compiler

Total time: 30 minutes 58 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

-
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 # 3546 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3546/

All tests passed

Build Log:
[...truncated 64592 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /tmp/ecj1814478960
 [ecj-lint] Compiling 48 source files to /tmp/ecj1814478960
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 23)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 28)
 [ecj-lint] public class MockInitialContextFactory implements 
InitialContextFactory {
 [ecj-lint]  ^
 [ecj-lint] The type MockInitialContextFactory must implement the inherited 
abstract method InitialContextFactory.getInitialContext(Hashtable)
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 30)
 [ecj-lint] private final javax.naming.Context context;
 [ecj-lint]   
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 33)
 [ecj-lint] context = mock(javax.naming.Context.class);
 [ecj-lint] ^^^
 [ecj-lint] context cannot be resolved to a variable
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 33)
 [ecj-lint] context = mock(javax.naming.Context.class);
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 36)
 [ecj-lint] when(context.lookup(anyString())).thenAnswer(invocation -> 
objects.get(invocation.getArgument(0)));
 [ecj-lint]  ^^^
 [ecj-lint] context cannot be resolved
 [ecj-lint] --
 [ecj-lint] 7. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 38)
 [ecj-lint] } catch (NamingException e) {
 [ecj-lint]  ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 8. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 45)
 [ecj-lint] public javax.naming.Context getInitialContext(Hashtable env) {
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 9. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 46)
 [ecj-lint] return context;
 [ecj-lint]^^^
 [ecj-lint] context cannot be resolved to a variable
 [ecj-lint] --
 [ecj-lint] 9 problems (9 errors)

BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:634: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:101: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build.xml:651:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/common-build.xml:479:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2015:
 The following error occurred while executing this line:

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-11.0.3) - Build # 5287 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5287/
Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 63955 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: 
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj2097838547
 [ecj-lint] Compiling 1285 source files to 
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj2097838547
 [ecj-lint] Processing annotations
 [ecj-lint] Annotations processed
 [ecj-lint] Processing annotations
 [ecj-lint] No elements to process
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/Users/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/Users/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
 (at line 219)
 [ecj-lint] return (NamedList) new 
JavaBinCodec(resolver).unmarshal(in);
 [ecj-lint]^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. WARNING in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 788)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 794)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 19)
 [ecj-lint] import javax.naming.Context;
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 20)
 [ecj-lint] import javax.naming.InitialContext;
 [ecj-lint]^^^
 [ecj-lint] The type javax.naming.InitialContext is not accessible
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 21)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 7. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 22)
 [ecj-lint] import javax.naming.NoInitialContextException;
 [ecj-lint]^^
 [ecj-lint] The type javax.naming.NoInitialContextException is not accessible
 [ecj-lint] --
 [ecj-lint] 8. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 776)
 [ecj-lint] Context c = new InitialContext();
 [ecj-lint] ^^^
 [ecj-lint] Context cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 9. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 776)
 [ecj-lint] Context c = new InitialContext();
 [ecj-lint] ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 10. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 779)
 [ecj-lint] } catch (NoInitialContextException e) {
 [ecj-lint]  ^
 [ecj-lint] NoInitialContextException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 11. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 781)
 [ecj-lint] } catch (NamingException e) {
 [ecj-lint]  ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 12. WARNING in 

RE: thetaphi jenkins RSS feed broken? (not showing up in fucit reports since July 24th)

[Uwe Schindler]

Hi,

sorry for the delay (was on vacation). This is a known issue in Jenkins 
introduced by a security fix. The issue is here:
https://issues.jenkins-ci.org/browse/JENKINS-58595

Although, this issue only talks about the dates in  and ; 
if you look at the code and the pull request, also the URL in the link is 
broken as it uses same mechanism. Only the base URL is correctly inserted.

It should be fixed in one of the next updates of Jenkins. In the latest one of 
today, no changes yet.

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Chris Hostetter 
> Sent: Wednesday, August 7, 2019 7:02 PM
> To: Uwe Schindler 
> Cc: Lucene Dev 
> Subject: thetaphi jenkins RSS feed broken? (not showing up in fucit reports
> since July 24th)
> 
> 
> Uwe: I just realized that my jenkins reports haven't mentioned any
> failures from your jenkins box all week -- and that's because aparently
> even though the the RSS feed is up to date, and lists recent jobs, the
> URLs are all "wrong" and so the script can't get the test results &
> logs.
>   http://fucit.org/solr-jenkins-reports/
> 
> 
> Note the "link" for this single entry currently in your RSS feed...
> 
> https://jenkins.thetaphi.de/view/Lucene-Solr/rssAll
> 
>   Lucene-Solr-master-Windows #8073 (9 more tests are failing (total
> 16))
>   https://jenkins.thetaphi.de/"/>
>   tag:hudson.dev.java.net,2019:Lucene-Solr-master-Windows:8073
>   
>   
>   Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -
> XX:+UseConcMarkSweepGC
> 
> 
> ...every "entry" in your jenkin's feed has that exact same idential link
> href -- just for the base URL of your server, w/o the job specifics path.
> 
> Also note, if it helps track down the problem, that the published &
> updated dates are also blank (which i think my RSS crawler could handle
> by assuming 'now' if the 'link' was valid)
> 
> The problem seems to have started on July 24th (that's the last time my
> scripts reported seeing a "new" jenkins job in our feed -- with a valid
> 'link')
> 
> 
> For contrast, compare to what entries from the apache jenkins RSS feed
> look like ...
> 
> https://builds.apache.org/view/L/view/Lucene/rssAll
> 
>   Lucene-Solr-Tests-master #3516 (broken since build #3515)
>href="https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-Tests-
> master/3516/"/>
>   tag:hudson.dev.java.net,2019:Lucene-Solr-Tests-master:3516
>   2019-08-07T14:12:25Z
>   2019-08-07T14:12:25Z
> 
> 
> 
> 
> -Hoss
> http://www.lucidworks.com/


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13125) Optimize Queries when sorting by router.field

[mosh (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906103#comment-16906103
 ] 

mosh commented on SOLR-13125:
-

{quote}What you would need to do is somehow influence the futures that solr is 
waiting on to return early and empty once your request has been filled up from 
the most recent collections. {quote}

After further investigation it seems like currently HttpShardHandler#take:288 
is designed to wait(block) for all shard requests.
{code:java}private ShardResponse take(boolean bailOnError) {

while (pending.size() > 0) {
  try {
Future future = completionService.take();
pending.remove(future);
ShardResponse rsp = future.get();
if (bailOnError && rsp.getException() != null) return rsp; // if 
exception, return immediately
// add response to the response list... we do this after the take() and
// not after the completion of "call" so we know when the last response
// for a request was received.  Otherwise we might return the same
// request more than once.
rsp.getShardRequest().responses.add(rsp);
if (rsp.getShardRequest().responses.size() == 
rsp.getShardRequest().actualShards.length) {
  return rsp;
}
  } catch (InterruptedException e) {
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
  } catch (ExecutionException e) {
// should be impossible... the problem with catching the exception
// at this level is we don't know what ShardRequest it applied to
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, 
"Impossible Exception",e);
  }
}
return null;
  }{code}
This seems counter intuitive to our goal of "short-circuiting" shard requests, 
once sufficient documents have been returned.
HttpShardHandler also seems out of scope for SearchComponents, at least using 
the current design, in which SearchComponents are coupled to a SearchHandler.

[~gus_heck], WDYT?
Do you have any idea of how this should be designed without significant code 
changes?
Bear in mind, this discussion only concerns optimizing TRA queries, and could 
be made abstract in due time (resembling the way RoutedAliases were 
implemented).

> Optimize Queries when sorting by router.field
> -
>
> Key: SOLR-13125
> URL: https://issues.apache.org/jira/browse/SOLR-13125
> Project: Solr
>  Issue Type: Sub-task
>Reporter: mosh
>Priority: Minor
> Attachments: SOLR-13125-no-commit.patch, SOLR-13125.patch, 
> SOLR-13125.patch, SOLR-13125.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We are currently testing TRA using Solr 7.7, having >300 shards in the alias, 
> with much growth in the coming months.
> The "hot" data(in our case, more recent) will be stored on stronger 
> nodes(SSD, more RAM, etc).
> A proposal of optimizing queries sorted by router.field(the field which TRA 
> uses to route the data to the correct collection) has emerged.
> Perhaps, in queries which are sorted by router.field, Solr could be smart 
> enough to wait for the more recent collections, and in case the limit was 
> reached cancel other queries(or just not block and wait for the results)?
> For example:
> When querying a TRA which with a filter on a different field than 
> router.field, but sorting by router.field desc, limit=100.
> Since this is a TRA, solr will issue queries for all the collections in the 
> alias.
> But to optimize this particular type of query, Solr could wait for the most 
> recent collection in the TRA, see whether the result set matches or exceeds 
> the limit. If so, the query could be returned to the user without waiting for 
> the rest of the shards. If not, the issuing node will block until the second 
> query returns, and so forth, until the limit of the request is reached.
> This might also be useful for deep paging, querying each collection and only 
> skipping to the next once there are no more results in the specified 
> collection.
> Thoughts or inputs are always welcome.
> This is just my two cents, and I'm always happy to brainstorm.
> Thanks in advance.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-8.x - Build # 399 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/399/

All tests passed

Build Log:
[...truncated 12348 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:634: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:578: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:59: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build.xml:231: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:506:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/common-build.xml:401:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:558:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2056:
 Error starting modern compiler

Total time: 72 minutes 25 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-13693) Use strongly-typed setters for cache parameters

[Andrzej Bialecki (JIRA)]

Andrzej Bialecki  created SOLR-13693:


 Summary: Use strongly-typed setters for cache parameters
 Key: SOLR-13693
 URL: https://issues.apache.org/jira/browse/SOLR-13693
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.3
Reporter: Andrzej Bialecki 
Assignee: Andrzej Bialecki 
 Fix For: 8.3


SOLR-13558 added ability to modify cache parameters on the fly. It uses an API 
similar to the originally proposed API in SOLR-13579. After several iterations 
of that patch it became clear that the originally proposed weakly-typed API 
should be replaced with a strongly-typed one.

Since it's a new API in 8.3 there are no back-compat considerations.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Solr Consultants

[Jan Høydahl]

Apache is a non-profit and this project does not employ, certify or recommend 
consultants. However we have made a Wiki page where a number of consultancies 
have self registered, so this should be a good starting point for you! 
https://cwiki.apache.org/confluence/display/SOLR/Support (warning, part of the 
content may be outdated)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 13. aug. 2019 kl. 12:14 skrev Michael James :
> 
> Hi,
>  
> I’m looking for a consultant to come and review our Solr configuration. Do 
> you have a list of approved consultants?
>  
> Michael James
> IT Systems Delivery Manager
> Virgin Money Giving 
>  
> +44 (0)1603 215 641
> +44 (0)7795 122 115
> michael.ja...@virginmoney.com 
> twitter: @virginmoney
> facebook: facebook.com/virginmoneyuk 
> Visit our fundraising website: virginmoneygiving.com 
> 
>  
> Virgin Money, Discovery House, Whiting Road, Norwich NR4 6EJ
>  
> 
> This message has been checked for viruses and spam by the Virgin Money email 
> scanning system powered by Messagelabs.
> 
> This e-mail is intended to be confidential to the recipient. If you receive a 
> copy in error, please inform the sender and then delete this message.
> 
> Virgin Money plc - Registered in England and Wales (Company no. 6952311). 
> Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. 
> Virgin Money plc is authorised by the Prudential Regulation Authority and 
> regulated by the Financial Conduct Authority and the Prudential Regulation 
> Authority.
> 
> The following companies also trade as Virgin Money. They are both authorised 
> and regulated by the Financial Conduct Authority, are registered in England 
> and Wales and have their registered office at Jubilee House, Gosforth, 
> Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited 
> (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company 
> no. 3000482).
> 
> For further details of Virgin Money group companies please visit our website 
> at virginmoney.com 

Solr Consultants

[Michael James]

Hi,

I'm looking for a consultant to come and review our Solr configuration. Do you 
have a list of approved consultants?

Michael James
IT Systems Delivery Manager
Virgin Money Giving

+44 (0)1603 215 641
+44 (0)7795 122 115
michael.ja...@virginmoney.com
twitter: @virginmoney
facebook: facebook.com/virginmoneyuk
Visit our fundraising website: virginmoneygiving.com

Virgin Money, Discovery House, Whiting Road, Norwich NR4 6EJ


This message has been checked for viruses and spam by the Virgin Money email 
scanning system powered by Messagelabs.

This e-mail is intended to be confidential to the recipient. If you receive a 
copy in error, please inform the sender and then delete this message.

Virgin Money plc - Registered in England and Wales (Company no. 6952311). 
Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. 
Virgin Money plc is authorised by the Prudential Regulation Authority and 
regulated by the Financial Conduct Authority and the Prudential Regulation 
Authority.

The following companies also trade as Virgin Money. They are both authorised 
and regulated by the Financial Conduct Authority, are registered in England and 
Wales and have their registered office at Jubilee House, Gosforth, Newcastle 
upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 
3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482).

For further details of Virgin Money group companies please visit our website at 
virginmoney.com

[JENKINS] Lucene-Solr-8.x-Linux (32bit/jdk1.8.0_201) - Build # 1008 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/1008/
Java: 32bit/jdk1.8.0_201 -server -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 12360 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:634: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:578: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:59: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build.xml:231: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:558: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:506: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/common-build.xml:401: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/common-build.xml:558: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/common-build.xml:2056: 
Error starting modern compiler

Total time: 39 minutes 29 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13188) NullPointerException in org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)

[Chongchen Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906057#comment-16906057
 ] 

Chongchen Chen commented on SOLR-13188:
---

I think [~mkhludnev]'s solution is correct.

> NullPointerException in 
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
> --
>
> Key: SOLR-13188
> URL: https://issues.apache.org/jira/browse/SOLR-13188
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Marek
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?q={!parent%20fq={!collapse%20field=id}}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> ERROR (qtp689401025-21) [   x:films] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
>   at 
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
>   at 
> org.apache.lucene.search.join.QueryBitSetProducer.getBitSet(QueryBitSetProducer.java:73)
>   at 
> org.apache.solr.search.join.BlockJoinParentQParser$BitDocIdSetFilterWrapper.getDocIdSet(BlockJoinParentQParser.java:135)
>   at 
> org.apache.solr.search.SolrConstantScoreQuery$ConstantWeight.scorer(SolrConstantScoreQuery.java:99)
>   at org.apache.lucene.search.Weight.bulkScorer(Weight.java:177)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:649)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:443)
>   at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:200)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1604)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1420)
>   at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:567)
>   at 
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1434)
>   at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:373)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   [...]
> {noformat}
> In org/apache/lucene/search/join/QueryBitSetProducer.java[73] there is called
>  method 'org.apache.lucene.search.IndexSearcher.rewrite' with null value 
> stored
>  in the member 'query'. Inside the called method there is method 

[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-13-rc) - Build # 396 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/396/
Java: 64bit/jdk-13-rc -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

19 tests failed.
FAILED:  
org.apache.solr.ltr.store.rest.TestModelManagerPersistence.testFilePersistence

Error Message:
An established connection was aborted by the software in your host machine

Stack Trace:
javax.net.ssl.SSLException: An established connection was aborted by the 
software in your host machine
at 
__randomizedtesting.SeedInfo.seed([941317EE7C144D7F:B6B27393D9782B3A]:0)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:324)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:267)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:262)
at 
java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1652)
at 
java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1038)
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.solr.util.RestTestHarness.getResponse(RestTestHarness.java:215)
at org.apache.solr.util.RestTestHarness.query(RestTestHarness.java:107)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:226)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
at 
org.apache.solr.ltr.store.rest.TestModelManagerPersistence.testFilePersistence(TestModelManagerPersistence.java:168)
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 
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)
  

[jira] [Issue Comment Deleted] (SOLR-13188) NullPointerException in org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)

[Chongchen Chen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chongchen Chen updated SOLR-13188:
--
Comment: was deleted

(was: I reproduced it.
It seems that the root cause is in QueryComponent.

{code:java}
public void process(ResponseBuilder rb) throws IOException
  {
//
GroupingSpecification groupingSpec = rb.getGroupingSpec();
if (groupingSpec != null) {
// 
}
// the groupingSpec is null, then query initialization is skipped. Maybe we 
should add some initialization here.
}
{code})

> NullPointerException in 
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
> --
>
> Key: SOLR-13188
> URL: https://issues.apache.org/jira/browse/SOLR-13188
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Marek
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?q={!parent%20fq={!collapse%20field=id}}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> ERROR (qtp689401025-21) [   x:films] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
>   at 
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
>   at 
> org.apache.lucene.search.join.QueryBitSetProducer.getBitSet(QueryBitSetProducer.java:73)
>   at 
> org.apache.solr.search.join.BlockJoinParentQParser$BitDocIdSetFilterWrapper.getDocIdSet(BlockJoinParentQParser.java:135)
>   at 
> org.apache.solr.search.SolrConstantScoreQuery$ConstantWeight.scorer(SolrConstantScoreQuery.java:99)
>   at org.apache.lucene.search.Weight.bulkScorer(Weight.java:177)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:649)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:443)
>   at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:200)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1604)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1420)
>   at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:567)
>   at 
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1434)
>   at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:373)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> 

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1928 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1928/

2 tests failed.
FAILED:  org.apache.solr.cloud.RollingRestartTest.test

Error Message:
Timeout occurred while waiting response from server at: 
http://127.0.0.1:35948/a_n/jj

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: http://127.0.0.1:35948/a_n/jj
at 
__randomizedtesting.SeedInfo.seed([23F60434E13D8FD4:ABA23BEE4FC1E22C]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:74)
at 
org.apache.solr.cloud.RollingRestartTest.test(RollingRestartTest.java:53)
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 

[GitHub] [lucene-solr] atris commented on issue #815: LUCENE-8213: Introduce Asynchronous Caching in LRUQueryCache

[GitBox]

atris commented on issue #815: LUCENE-8213: Introduce Asynchronous Caching in 
LRUQueryCache
URL: https://github.com/apache/lucene-solr/pull/815#issuecomment-520776996
 
 
   > It should be enough to report the stats after the last iteration - it is 
cumulative, so the previous ones just add noise? I agree QPS looks pretty 
noisy, probably no real change. 
   
   I dont think thats true, since each run is its own JVM?
   
   


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] [Comment Edited] (SOLR-13188) NullPointerException in org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)

[Chongchen Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906000#comment-16906000
 ] 

Chongchen Chen edited comment on SOLR-13188 at 8/13/19 10:09 AM:
-

I reproduced it.
It seems that the root cause is in QueryComponent.

{code:java}
public void process(ResponseBuilder rb) throws IOException
  {
//
GroupingSpecification groupingSpec = rb.getGroupingSpec();
if (groupingSpec != null) {
// 
}
// the groupingSpec is null, then query initialization is skipped. Maybe we 
should add some initialization here.
}
{code}


was (Author: nppoly):
I reproduced it.
It seems that the root cause is in QueryComponent.

{code:java}
public void process(ResponseBuilder rb) throws IOException
  {
//
GroupingSpecification groupingSpec = rb.getGroupingSpec();
if (groupingSpec != null) {
// 
}
// the groupingSpec is null, then query initialization is skipped.
}
{code}

> NullPointerException in 
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
> --
>
> Key: SOLR-13188
> URL: https://issues.apache.org/jira/browse/SOLR-13188
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Marek
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?q={!parent%20fq={!collapse%20field=id}}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> ERROR (qtp689401025-21) [   x:films] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
>   at 
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
>   at 
> org.apache.lucene.search.join.QueryBitSetProducer.getBitSet(QueryBitSetProducer.java:73)
>   at 
> org.apache.solr.search.join.BlockJoinParentQParser$BitDocIdSetFilterWrapper.getDocIdSet(BlockJoinParentQParser.java:135)
>   at 
> org.apache.solr.search.SolrConstantScoreQuery$ConstantWeight.scorer(SolrConstantScoreQuery.java:99)
>   at org.apache.lucene.search.Weight.bulkScorer(Weight.java:177)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:649)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:443)
>   at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:200)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1604)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1420)
>   at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:567)
>   at 
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1434)
>   at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:373)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)

RE: Jira Upgrade August 19th 0500 UTC

[Uwe Schindler]

Hi John, hi committers,

This is great news. As a Lucene committer, I was waiting for this since long 
time!

> Please be aware that Jira (https://issues.apache.org/jira) will be
> unavailable for approximately 4 hours beginning August 19, 2019 0500
> UTC for migration to new hardware and upgrades to the Jira Software
> suite of tools including all plugins and the major version of Jira.
> For more details on what is new in Jira 8.x you can look at the
> release notes
> 
> https://confluence.atlassian.com/jirasoftware/jira-software-8-0-x-release-
> notes-957981626.html

This version of JIRA also ships with a new version of Apache Lucene instead of 
the stone-aged Apache Lucene 3.3.0 integration. Next to speed improvements and 
much smaller indexes, the new version also hopefully fixes the scoring issues 
when you quicksearch (top-right) for issues - often showing irrelevant results 
first. I worked together with Atlassian last year to revamp the Apache Lucene 
integration and we used the new Lucene features like index-joins to improve 
scoring, and numeric/point field types for date searches and usage of DocValues 
for sorting. Also complex permission schemes are now much faster due to 
denormalization . FYI, Lucene in JIRA is now on 7.3.1.

Here is the talk:
https://archive.fosdem.org/2019/schedule/event/lucene_upgrade_jira_8/

@John: Please keep in mind that the upgrade to JIRA 8 requires a full 
reindexing of all issues. Although it's faster now, it still takes some 
significant time, especially if the database is on a different machine. But in 
the future, regular reindexing should no longer be needed, as Lucene now uses 
checksums and fsyncs on the directory metadata to prevent consistency issues on 
power outages or other crashes. Also JIRA no longer "optimizes" (aka 
force-merge) indexes, which is not recommended for indexes that have high 
update rates. Due to the use of DocValues for sorting, the heap-space 
requirements of JIRA lowered quite a lot! Also keep in mind to have at least 50 
% of physical RAM available for memory-mapping of indexes, so reduce heap size 
accordingly.

You can contact me, if you need some advice on installation!

Uwe

-
Uwe Schindler
uschind...@apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
https://lucene.apache.org/



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13188) NullPointerException in org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906005#comment-16906005
 ] 

Mikhail Khludnev commented on SOLR-13188:
-

I suppose there should be NPE check somewhere around 
https://github.com/apache/lucene-solr/blob/07ca02b7375a9c2564aba4c905e880a32d16e1df/solr/core/src/java/org/apache/solr/search/join/BlockJoinParentQParser.java#L59

> NullPointerException in 
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
> --
>
> Key: SOLR-13188
> URL: https://issues.apache.org/jira/browse/SOLR-13188
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Marek
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?q={!parent%20fq={!collapse%20field=id}}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> ERROR (qtp689401025-21) [   x:films] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
>   at 
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
>   at 
> org.apache.lucene.search.join.QueryBitSetProducer.getBitSet(QueryBitSetProducer.java:73)
>   at 
> org.apache.solr.search.join.BlockJoinParentQParser$BitDocIdSetFilterWrapper.getDocIdSet(BlockJoinParentQParser.java:135)
>   at 
> org.apache.solr.search.SolrConstantScoreQuery$ConstantWeight.scorer(SolrConstantScoreQuery.java:99)
>   at org.apache.lucene.search.Weight.bulkScorer(Weight.java:177)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:649)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:443)
>   at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:200)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1604)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1420)
>   at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:567)
>   at 
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1434)
>   at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:373)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   [...]
> {noformat}
> In org/apache/lucene/search/join/QueryBitSetProducer.java[73] 

[jira] [Commented] (SOLR-13188) NullPointerException in org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)

[Chongchen Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906000#comment-16906000
 ] 

Chongchen Chen commented on SOLR-13188:
---

I reproduced it.
It seems that the root cause is in QueryComponent.

{code:java}
public void process(ResponseBuilder rb) throws IOException
  {
//
GroupingSpecification groupingSpec = rb.getGroupingSpec();
if (groupingSpec != null) {
// 
}
// the groupingSpec is null, then query initialization is skipped.
}
{code}

> NullPointerException in 
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
> --
>
> Key: SOLR-13188
> URL: https://issues.apache.org/jira/browse/SOLR-13188
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Marek
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?q={!parent%20fq={!collapse%20field=id}}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> ERROR (qtp689401025-21) [   x:films] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
>   at 
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
>   at 
> org.apache.lucene.search.join.QueryBitSetProducer.getBitSet(QueryBitSetProducer.java:73)
>   at 
> org.apache.solr.search.join.BlockJoinParentQParser$BitDocIdSetFilterWrapper.getDocIdSet(BlockJoinParentQParser.java:135)
>   at 
> org.apache.solr.search.SolrConstantScoreQuery$ConstantWeight.scorer(SolrConstantScoreQuery.java:99)
>   at org.apache.lucene.search.Weight.bulkScorer(Weight.java:177)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:649)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:443)
>   at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:200)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1604)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1420)
>   at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:567)
>   at 
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1434)
>   at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:373)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> 

[GitHub] [lucene-solr] janhoy commented on issue #805: SOLR-13649 change the default behavior of the basic authentication plugin.

[GitBox]

janhoy commented on issue #805: SOLR-13649 change the default behavior of the 
basic authentication plugin.
URL: https://github.com/apache/lucene-solr/pull/805#issuecomment-520754094
 
 
   My comment about ERROR above was related to the special case where people 
initialize security.json without any users, like `"authentication": 
{"class":"solr.BasicAuthPlugin"}`. In this case today nothing will happen since 
blockUnknown=false, but when we change the default, the entire cluster is 
completely locked for everyone. So my question was whether to allow such a 
config at all, or to allow configs with no users only if blockUnknown is 
explicitly set to false.


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] [Resolved] (SOLR-13682) command line option to export data to a file

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul resolved SOLR-13682.
---
   Resolution: Fixed
Fix Version/s: 8.3

> command line option to export data to a file
> 
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into 
> a file called {{gettingstarted.json}}
> additional options are
>  * {{format}} : {{jsonl}} (default) or {{javabin}}
>  * {{out}} : export file name 
>  * {{query}} : a custom query , default is **:**
>  * {{fields}}: a comma separated list of fields to be exported
>  * {{limit}} : no:of docs. default is 100 , send  {{-1}} to import all the 
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json 
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary 
> @gettingstarted.javabin 
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true

[Marcus Eagan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905973#comment-16905973
 ] 

Marcus Eagan commented on SOLR-13649:
-

My apologies. I thought that an error was what you were requesting. I will 
revert that change in the morning. 

> BasicAuth's 'blockUnknown' param should default to true
> ---
>
> Key: SOLR-13649
> URL: https://issues.apache.org/jira/browse/SOLR-13649
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI, Authentication, security
>Affects Versions: 7.7.2, 8.1.1
> Environment: All
>Reporter: Marcus Eagan
>Priority: Major
>  Labels: Authentication
> Fix For: master (9.0)
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> If someone seeks to enable basic authentication but they do not specify the 
> {{blockUnknown}} parameter, the default value is {{false}}. That default 
> behavior is a bit counterintuitive because if someone wishes to enable basic 
> authentication, you would expect that they would want all unknown users to 
> need to authenticate by default. I can imagine cases where you would not, but 
> those cases would be less frequent.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13688) Make the bin/solr export command to run one thread per shard

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905971#comment-16905971
 ] 

ASF subversion and git services commented on SOLR-13688:


Commit 03fd3d3923b65c9829c58f1bf24d5859cee6369e in lucene-solr's branch 
refs/heads/branch_8x from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=03fd3d3 ]

SOLR-13688: Run the bin/solr export command multithreaded


> Make the bin/solr export command to run one thread per shard
> 
>
> Key: SOLR-13688
> URL: https://issues.apache.org/jira/browse/SOLR-13688
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> This can be run in parallel with one dedicated thread for each shard and 
> (distrib=false) option
> this will be the only option



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org