[JENKINS] Lucene-Solr-BadApples-8.x-Linux (64bit/jdk-12) - Build # 63 - Unstable!

2019-05-23 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-8.x-Linux/63/
Java: 64bit/jdk-12 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader

Error Message:
Doc with id=4 not found in 
http://127.0.0.1:34463/solr/outOfSyncReplicasCannotBecomeLeader-false due to: 
Path not found: /id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=4 not found in 
http://127.0.0.1:34463/solr/outOfSyncReplicasCannotBecomeLeader-false due to: 
Path not found: /id; rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([1AD25F5793DC2452:64397F4750BB2B68]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.TestCloudConsistency.assertDocExists(TestCloudConsistency.java:283)
at 
org.apache.solr.cloud.TestCloudConsistency.assertDocsExistInAllReplicas(TestCloudConsistency.java:267)
at 
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader(TestCloudConsistency.java:138)
at 
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader(TestCloudConsistency.java:97)
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)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Updated] (SOLR-13488) Improve supported syntax in Utils.getObjectByPath()

2019-05-23 Thread Noble Paul (JIRA)


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

Noble Paul updated SOLR-13488:
--
Summary: Improve supported syntax in Utils.getObjectByPath()  (was: Improve 
supported syntax Utils.getObjectByPath())

> Improve supported syntax in Utils.getObjectByPath()
> ---
>
> Key: SOLR-13488
> URL: https://issues.apache.org/jira/browse/SOLR-13488
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> Today the supported paths are in the form of 
> *  {{/a/b/c}} : c inside a/b
> * {{/a/b[0]}} : first element of b
> * {{/a/b[-1]}} : last element of b
> we need to add support for the following to improve testing
>  
>  * {{/a/b[@x]/c}} : c where attribute x is present for b
>  * {{/a/b[@x == 'y']/c}} : c where x has a value y in b
>  * {{/a/b[@x != 'y']/c}} : c where x has a value not equals y in b
>  * {{/a/b/$size()}} : size of b where b is a map or collection
> This is widely used in our tests and this can enable us to write better tests
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-13488) Improve supported syntax Utils.getObjectByPath()

2019-05-23 Thread Noble Paul (JIRA)


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

Noble Paul updated SOLR-13488:
--
Description: 
Today the supported paths are in the form of 

*  {{/a/b/c}} : c inside a/b
* {{/a/b[0]}} : first element of b
* {{/a/b[-1]}} : last element of b

we need to add support for the following to improve testing

 
 * {{/a/b[@x]/c}} : c where attribute x is present for b
 * {{/a/b[@x == 'y']/c}} : c where x has a value y in b
 * {{/a/b[@x != 'y']/c}} : c where x has a value not equals y in b
 * {{/a/b/$size()}} : size of b where b is a map or collection

This is widely used in our tests and this can enable us to write better tests
 

  was:

Today the supported paths are in the form of 

*  {{/a/b/c}} : c inside a/b
* {{/a/b[0]}} : first element of b
* {{/a/b[-1]}} : last element of b

we need to add support for the following to improve testing

 
 * {{/a/b[@x]/c}} : c where attribute x is present for b
 * {{/a/b[@x == 'y']/c}} : c where x has a value y in b
 * {{/a/b[@x != 'y']/c}} : c where x has a value not equals y in b
 * {{/a/b/$size()}} : size of b where b is a map or collection
 


> Improve supported syntax Utils.getObjectByPath()
> 
>
> Key: SOLR-13488
> URL: https://issues.apache.org/jira/browse/SOLR-13488
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> Today the supported paths are in the form of 
> *  {{/a/b/c}} : c inside a/b
> * {{/a/b[0]}} : first element of b
> * {{/a/b[-1]}} : last element of b
> we need to add support for the following to improve testing
>  
>  * {{/a/b[@x]/c}} : c where attribute x is present for b
>  * {{/a/b[@x == 'y']/c}} : c where x has a value y in b
>  * {{/a/b[@x != 'y']/c}} : c where x has a value not equals y in b
>  * {{/a/b/$size()}} : size of b where b is a map or collection
> This is widely used in our tests and this can enable us to write better tests
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Created] (SOLR-13488) Improve supported syntax Utils.getObjectByPath()

2019-05-23 Thread Noble Paul (JIRA)
Noble Paul created SOLR-13488:
-

 Summary: Improve supported syntax Utils.getObjectByPath()
 Key: SOLR-13488
 URL: https://issues.apache.org/jira/browse/SOLR-13488
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul



Today the supported paths are in the form of 

*  {{/a/b/c}} : c inside a/b
* {{/a/b[0]}} : first element of b
* {{/a/b[-1]}} : last element of b

we need to add support for the following to improve testing

 
 * {{/a/b[@x]/c}} : c where attribute x is present for b
 * {{/a/b[@x == 'y']/c}} : c where x has a value y in b
 * {{/a/b[@x != 'y']/c}} : c where x has a value not equals y in b
 * {{/a/b/$size()}} : size of b where b is a map or collection
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-NightlyTests-7.7 - Build # 19 - Still Unstable

2019-05-23 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.7/19/

4 tests failed.
FAILED:  
org.apache.lucene.classification.utils.ConfusionMatrixGeneratorTest.testGetConfusionMatrixWithBM25NB

Error Message:
expected:<7> but was:<6>

Stack Trace:
java.lang.AssertionError: expected:<7> but was:<6>
at 
__randomizedtesting.SeedInfo.seed([4EAA3B5ECE16FEAD:F541BDBC1D7F1BE2]: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.lucene.classification.utils.ConfusionMatrixGeneratorTest.checkCM(ConfusionMatrixGeneratorTest.java:110)
at 
org.apache.lucene.classification.utils.ConfusionMatrixGeneratorTest.testGetConfusionMatrixWithBM25NB(ConfusionMatrixGeneratorTest.java:135)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.lucene.index.TestIndexWriterDelete.testDeletesOnDiskFull

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([46541D0A0C25A259]:0)


FAILED:  junit.framework.TestSuite.org.apache.lucene.index.TestIndexWriterDelete

Error 

[jira] [Commented] (LUCENE-8810) Flattening of nested disjunctions does not take into account number of clause limitation of builder

2019-05-23 Thread Atri Sharma (JIRA)


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

Atri Sharma commented on LUCENE-8810:
-

[~msauvee] I am not able to understand what is the actual issue that you are 
seeing here. Given that a single Builder cannot have more than 1024 clauses, 
your inner builder is erroring out which is the expected behaviour.

 

I am curious to think of a parallel implication here though. What is the 
expected semantic when a nested disjunction which will be flattened exceeds the 
total clause count, when combined with the parent boolean query? I.e. if the 
parent query had 601 clauses, where one of the clauses was a disjunction 
containing another 600 clauses, will this query be treated as a valid query (it 
is treated as valid today). Is this the correct invariant?

> Flattening of nested disjunctions does not take into account number of clause 
> limitation of builder
> ---
>
> Key: LUCENE-8810
> URL: https://issues.apache.org/jira/browse/LUCENE-8810
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 8.0
>Reporter: Mickaël Sauvée
>Priority: Minor
> Fix For: 8.1.1
>
>
> In org.apache.lucene.search.BooleanQuery, at the end of the function 
> rewrite(IndexReader reader), the query is rewritten to flatten nested 
> disjunctions.
> This does not take into account the limitation on the number of clauses in a 
> builder (1024).
>  In some circumstances, this limite can be reached, hence an exception is 
> thrown.
> Here is a unit test that highlight this.
> {code:java}
>   public void testFlattenInnerDisjunctionsWithMoreThan1024Terms() throws 
> IOException {
> IndexSearcher searcher = newSearcher(new MultiReader());
> BooleanQuery.Builder builder1024 = new BooleanQuery.Builder();
> for(int i = 0; i < 1024; i++) {
>   builder1024.add(new TermQuery(new Term("foo", "bar-" + i)), 
> Occur.SHOULD);
> }
> Query inner = builder1024.build();
> Query query = new BooleanQuery.Builder()
> .add(inner, Occur.SHOULD)
> .add(new TermQuery(new Term("foo", "baz")), Occur.SHOULD)
> .build();
> searcher.rewrite(query);
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-13434) OpenTracing support for Solr

2019-05-23 Thread Haochao Zhuang (JIRA)


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

Haochao Zhuang commented on SOLR-13434:
---

I am trying to do that through Apache Skywalking.

I have a issue on Apache Skywalking. so may i join this.

> OpenTracing support for Solr
> 
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and 
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger, 
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing 
> APIs. Ideally, we can implement it once and have integrations for popular 
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack 
> of activity so this is a fresh attempt at solving this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-repro - Build # 3294 - Unstable

2019-05-23 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-repro/3294/

[...truncated 29 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.7/18/consoleText

[repro] Revision: fced8ab89e98c565166059e5052d3bc700468199

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.7/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=TestConcurrentMergeScheduler 
-Dtests.method=testFlushExceptions -Dtests.seed=730AC7E1D88016C6 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.7/test-data/enwiki.random.lines.txt
 -Dtests.locale=hr -Dtests.timezone=Asia/Pyongyang -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
379e6f64b80918dd98a573c78be68fa901d70d5d
[repro] git fetch
[repro] git checkout fced8ab89e98c565166059e5052d3bc700468199

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]lucene/core
[repro]   TestConcurrentMergeScheduler
[repro] ant compile-test

[...truncated 180 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestConcurrentMergeScheduler" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.7/test-data/enwiki.random.lines.txt
 -Dtests.seed=730AC7E1D88016C6 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.7/test-data/enwiki.random.lines.txt
 -Dtests.locale=hr -Dtests.timezone=Asia/Pyongyang -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[...truncated 152 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   1/5 failed: org.apache.lucene.index.TestConcurrentMergeScheduler
[repro] git checkout 379e6f64b80918dd98a573c78be68fa901d70d5d

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 6 lines...]

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1854 - Still Unstable

2019-05-23 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1854/

2 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsTlogReplayBufferedWhileIndexingTest.test

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([97127C10F1843A6]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsTlogReplayBufferedWhileIndexingTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([97127C10F1843A6]:0)




Build Log:
[...truncated 15468 lines...]
   [junit4] Suite: 
org.apache.solr.cloud.hdfs.HdfsTlogReplayBufferedWhileIndexingTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/build/solr-core/test/J0/temp/solr.cloud.hdfs.HdfsTlogReplayBufferedWhileIndexingTest_97127C10F1843A6-001/init-core-data-001
   [junit4]   2> 104742 WARN  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2 numCloses=2
   [junit4]   2> 104743 INFO  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 104745 INFO  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl="None")
   [junit4]   2> 104745 INFO  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> 104746 INFO  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 105950 WARN  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.a.h.u.NativeCodeLoader Unable to load native-hadoop library for your 
platform... using builtin-java classes where applicable
   [junit4]   1> Formatting using clusterid: testClusterID
   [junit4]   2> 107593 WARN  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.a.h.m.i.MetricsConfig Cannot locate configuration: tried 
hadoop-metrics2-namenode.properties,hadoop-metrics2.properties
   [junit4]   2> 107879 WARN  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.a.h.h.HttpRequestLog Jetty request log can only be enabled using Log4j
   [junit4]   2> 107919 INFO  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.e.j.s.Server jetty-9.4.14.v20181114; built: 2018-11-14T21:20:31.478Z; 
git: c4550056e785fb5665914545889f21dc136ad9e6; jvm 11.0.1+13-LTS
   [junit4]   2> 107922 INFO  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.e.j.s.session DefaultSessionIdManager workerName=node0
   [junit4]   2> 107923 INFO  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.e.j.s.session No SessionScavenger set, using defaults
   [junit4]   2> 107923 INFO  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.e.j.s.session node0 Scavenging every 66ms
   [junit4]   2> 107925 INFO  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@6186339{static,/static,jar:file:/x1/jenkins/.ivy2/cache/org.apache.hadoop/hadoop-hdfs/tests/hadoop-hdfs-3.2.0-tests.jar!/webapps/static,AVAILABLE}
   [junit4]   2> 108359 INFO  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.e.j.s.h.ContextHandler Started 
o.e.j.w.WebAppContext@9f2733f{hdfs,/,file:///x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/build/solr-core/test/J0/temp/jetty-localhost-41042-hdfs-_-any-11080779452450029231.dir/webapp/,AVAILABLE}{/hdfs}
   [junit4]   2> 108362 INFO  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.e.j.s.AbstractConnector Started 
ServerConnector@1e9fa992{HTTP/1.1,[http/1.1]}{localhost:41042}
   [junit4]   2> 108362 INFO  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.e.j.s.Server Started @108437ms
   [junit4]   2> 109315 WARN  
(SUITE-HdfsTlogReplayBufferedWhileIndexingTest-seed#[97127C10F1843A6]-worker) [ 
   ] o.a.h.h.HttpRequestLog Jetty request log can only be enabled using Log4j
   [junit4]   2> 109320 INFO  

[jira] [Resolved] (SOLR-13484) autoscaling/diagnostics APIshould be able to give diagnostics output from config pasted as a payload

2019-05-23 Thread Noble Paul (JIRA)


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

Noble Paul resolved SOLR-13484.
---
   Resolution: Fixed
Fix Version/s: 8.2

> autoscaling/diagnostics APIshould be able to give diagnostics output from 
> config pasted as a payload
> 
>
> Key: SOLR-13484
> URL: https://issues.apache.org/jira/browse/SOLR-13484
> 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.2
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the diagnostics from 
> autoscaling configuration sent as a payload . T
> {code:javascript}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/diagnostics
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-13484) autoscaling/diagnostics APIshould be able to give diagnostics output from config pasted as a payload

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13484:


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

SOLR-13484: autoscaling/diagnostics APIshould be able to give diagnostics 
output from config pasted as a payload


> autoscaling/diagnostics APIshould be able to give diagnostics output from 
> config pasted as a payload
> 
>
> Key: SOLR-13484
> URL: https://issues.apache.org/jira/browse/SOLR-13484
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the diagnostics from 
> autoscaling configuration sent as a payload . T
> {code:javascript}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/diagnostics
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-13484) autoscaling/diagnostics APIshould be able to give diagnostics output from config pasted as a payload

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13484:


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

SOLR-13484: autoscaling/diagnostics APIshould be able to give diagnostics 
output from config pasted as a payload


> autoscaling/diagnostics APIshould be able to give diagnostics output from 
> config pasted as a payload
> 
>
> Key: SOLR-13484
> URL: https://issues.apache.org/jira/browse/SOLR-13484
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the diagnostics from 
> autoscaling configuration sent as a payload . T
> {code:javascript}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/diagnostics
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-13484) autoscaling/diagnostics APIshould be able to give diagnostics output from config pasted as a payload

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13484:


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

SOLR-13484: backporting


> autoscaling/diagnostics APIshould be able to give diagnostics output from 
> config pasted as a payload
> 
>
> Key: SOLR-13484
> URL: https://issues.apache.org/jira/browse/SOLR-13484
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the diagnostics from 
> autoscaling configuration sent as a payload . T
> {code:javascript}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/diagnostics
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-13484) autoscaling/diagnostics APIshould be able to give diagnostics output from config pasted as a payload

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13484:


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

SOLR-13484:
autoscaling/diagnostics APIshould be able to give diagnostics output from 
config pasted as a payload


> autoscaling/diagnostics APIshould be able to give diagnostics output from 
> config pasted as a payload
> 
>
> Key: SOLR-13484
> URL: https://issues.apache.org/jira/browse/SOLR-13484
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the diagnostics from 
> autoscaling configuration sent as a payload . T
> {code:javascript}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/diagnostics
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



Re: [VOTE] Release Lucene/Solr 8.1.1 RC1

2019-05-23 Thread Jan Høydahl
+1. Just ran the smoke tester. macOs

SUCCESS! [1:36:12.343605]

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

> 22. mai 2019 kl. 19:46 skrev Andrzej Białecki :
> 
> Please vote for release candidate 1 for Lucene/Solr 8.1.1.
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.1-RC1-revfcbe46c28cef11bc058779afba09521de1b19bef
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.1-RC1-revfcbe46c28cef11bc058779afba09521de1b19bef
> 
> 
> Here's my +1
> SUCCESS! [1:00:35.149875]
> 
> —
> 
> Andrzej Białecki
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 



[JENKINS] Lucene-Solr-SmokeRelease-7.7 - Build # 20 - Failure

2019-05-23 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.7/20/

No tests ran.

Build Log:
[...truncated 23463 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 2465 links (2015 relative) to 3226 anchors in 246 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr-ref-guide/bare-bones-html/

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

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/package/solr-7.7.2.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/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-7.7/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-7.7/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-7.7/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-7.7/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-7.7/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-7.7/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-7.7/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-7.7/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-7.7/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-7.7/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-7.7/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:

Re: [JENKINS] Lucene-Solr-NightlyTests-7.7 - Build # 18 - Still Unstable

2019-05-23 Thread Jan Høydahl
I see this test failing now and then for the last year.
I have not studied the stack traces, can you say a few more words about what 
you found and why it may be serious?

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

> 23. mai 2019 kl. 12:29 skrev Dawid Weiss :
> 
> Hmm... this looks serious, no?
> D.
> 
> On Thu, May 23, 2019 at 2:27 AM Apache Jenkins Server
>  wrote:
>> 
>> Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.7/18/
>> 
>> 1 tests failed.
>> FAILED:  
>> org.apache.lucene.index.TestConcurrentMergeScheduler.testFlushExceptions
>> 
>> Error Message:
>> 
>> 
>> Stack Trace:
>> java.lang.AssertionError
>>at 
>> __randomizedtesting.SeedInfo.seed([730AC7E1D88016C6:C760943BD16080F2]:0)
>>at org.junit.Assert.fail(Assert.java:86)
>>at org.junit.Assert.assertTrue(Assert.java:41)
>>at org.junit.Assert.assertTrue(Assert.java:52)
>>at 
>> org.apache.lucene.index.TestConcurrentMergeScheduler.testFlushExceptions(TestConcurrentMergeScheduler.java:128)
>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>at java.lang.reflect.Method.invoke(Method.java:498)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
>>at 
>> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
>>at 
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>>at 
>> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
>>at 
>> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>>at 
>> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>>at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>>at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
>>at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
>>at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
>>at 
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>>at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>>at 
>> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
>>at 
>> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
>>at 
>> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
>>at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>>at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>>at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>>at 
>> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
>>at 
>> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>>at 
>> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>>at 
>> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
>>at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>>at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
>>at java.lang.Thread.run(Thread.java:748)
>> 
>> 
>> 
>> 
>> Build Log:
>> [...truncated 991 lines...]
>>   

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

2019-05-23 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-13452:


FYI, on Saturday I will roll this to a new SOLR-13452_gradle_2 branch as I 
would like to do a clean rebase and catch things back up to master.  Rather 
than force pushing, I'll roll the branch.

> 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
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mark Miller
>Priority: Major
>
> 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]
> By default, dependencies are not transitive, but there is a special 
> Configuration for adding dependencies on other project internal modules that 
> are transitive to their direct external dependencies (their jar libs).
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



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

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13452:


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

SOLR-13452: Fix variable name.


> 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
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mark Miller
>Priority: Major
>
> 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]
> By default, dependencies are not transitive, but there is a special 
> Configuration for adding dependencies on other project internal modules that 
> are transitive to their direct external dependencies (their jar libs).
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



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

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13452:


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

SOLR-13452: Get the basics of jarChecksum working.


> 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
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mark Miller
>Priority: Major
>
> 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]
> By default, dependencies are not transitive, but there is a special 
> Configuration for adding dependencies on other project internal modules that 
> are transitive to their direct external dependencies (their jar libs).
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[GitHub] [lucene-solr] noblepaul commented on a change in pull request #685: SOLR-13434: OpenTracing support for Solr

2019-05-23 Thread GitBox
noblepaul commented on a change in pull request #685: SOLR-13434: OpenTracing 
support for Solr
URL: https://github.com/apache/lucene-solr/pull/685#discussion_r287096815
 
 

 ##
 File path: 
solr/contrib/jaegertracer-configurator/src/java/org/apache/solr/JaegerTracerConfigurator.java
 ##
 @@ -0,0 +1,91 @@
+/*
+ * 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.solr;
 
 Review comment:
   We need a sub-package name @CaoManhDat . 


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-13331) Atomic Update Multivalue remove does not work

2019-05-23 Thread Noble Paul (JIRA)


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

Noble Paul commented on SOLR-13331:
---

bq. But the 200 or so other Solr contributors won't. 

I think you are confused where it is used. NamedLists are not deserialized as 
BAUCS by default. You get Strings only by default. You have to explicitly ask 
for it (JavabinCodec#setReadStringAsCharSeq(boolean flag)). Today there are 
only 2 places it is used. 
* JavabinLoader . This is where we are seeing bugs today. I hope they will go 
away , if we make all the tests send docs in all formats
* HttpShardHandler . It uses javabin 100% of the time. So the format issue does 
not arise.

> Atomic Update Multivalue remove does not work
> -
>
> Key: SOLR-13331
> URL: https://issues.apache.org/jira/browse/SOLR-13331
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.7, 7.7.1, 8.0
> Environment: Standalone Solr Server
>Reporter: Thomas Wöckinger
>Assignee: Jason Gerlowski
>Priority: Critical
>  Labels: patch, pull-request-available, ready-to-commit, test
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, 
> SOLR-13331.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When using JavaBinCodec the values of collections are of type 
> ByteArrayUtf8CharSequence, existing field values are Strings so the remove 
> Operation does not have any effect.
> The relevant code is located in class AtomicUpdateDocumentMerger method 
> doRemove.
> The method parameter fieldVal contains the collection values of type 
> ByteArrayUtf8CharSequence, the variable original contains the collection of 
> Strings



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-13434) OpenTracing support for Solr

2019-05-23 Thread Wei-Chiu Chuang (JIRA)


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

Wei-Chiu Chuang commented on SOLR-13434:


Note similar efforts in HADOOP-15566, PHOENIX-5215, HBASE-22120 and HIVE-19685.

> OpenTracing support for Solr
> 
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and 
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger, 
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing 
> APIs. Ideally, we can implement it once and have integrations for popular 
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack 
> of activity so this is a fresh attempt at solving this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



RE: [VOTE] Release Lucene/Solr 8.1.1 RC1

2019-05-23 Thread Uwe Schindler
Hi Andrzej,

Policeman Jenkins smoked the release with Java 8 and 9: 
https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/23/console
SUCCESS! [2:51:07.911178]
Finished: SUCCESS

I also downloaded the artifacts o my local machine and looked around, checked 
changes and documentation. I can confirm that Solr starts successfully in Java 
8 and Java 11 on Windows including Whitespace in the file path 

Here is my +1

Docs look fine,
Uwe

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

> -Original Message-
> From: Andrzej Białecki 
> Sent: Wednesday, May 22, 2019 7:46 PM
> To: Lucene Dev 
> Subject: [VOTE] Release Lucene/Solr 8.1.1 RC1
> 
> Please vote for release candidate 1 for Lucene/Solr 8.1.1.
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.1-RC1-
> revfcbe46c28cef11bc058779afba09521de1b19bef
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.1-RC1-
> revfcbe46c28cef11bc058779afba09521de1b19bef
> 
> 
> Here's my +1
> SUCCESS! [1:00:35.149875]
> 
> —
> 
> Andrzej Białecki
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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



[jira] [Commented] (LUCENE-8784) Nori(Korean) tokenizer removes the decimal point.

2019-05-23 Thread Namgyu Kim (JIRA)


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

Namgyu Kim commented on LUCENE-8784:


Oh, I forgot.
I also added Javadoc for discardPunctuation in your patch. (KoreanAnalyzer, 
KoreanTokenizerFactory)

>  Nori(Korean) tokenizer removes the decimal point. 
> ---
>
> Key: LUCENE-8784
> URL: https://issues.apache.org/jira/browse/LUCENE-8784
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Munkyu Im
>Priority: Major
> Attachments: LUCENE-8784.patch, LUCENE-8784.patch, LUCENE-8784.patch
>
>
> This is the same issue that I mentioned to 
> [https://github.com/elastic/elasticsearch/issues/41401#event-2293189367]
> unlike standard analyzer, nori analyzer removes the decimal point.
> nori tokenizer removes "." character by default.
>  In this case, it is difficult to index the keywords including the decimal 
> point.
> It would be nice if there had the option whether add a decimal point or not.
> Like Japanese tokenizer does,  Nori need an option to preserve decimal point.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (LUCENE-8784) Nori(Korean) tokenizer removes the decimal point.

2019-05-23 Thread Namgyu Kim (JIRA)


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

Namgyu Kim updated LUCENE-8784:
---
Attachment: LUCENE-8784.patch

>  Nori(Korean) tokenizer removes the decimal point. 
> ---
>
> Key: LUCENE-8784
> URL: https://issues.apache.org/jira/browse/LUCENE-8784
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Munkyu Im
>Priority: Major
> Attachments: LUCENE-8784.patch, LUCENE-8784.patch, LUCENE-8784.patch
>
>
> This is the same issue that I mentioned to 
> [https://github.com/elastic/elasticsearch/issues/41401#event-2293189367]
> unlike standard analyzer, nori analyzer removes the decimal point.
> nori tokenizer removes "." character by default.
>  In this case, it is difficult to index the keywords including the decimal 
> point.
> It would be nice if there had the option whether add a decimal point or not.
> Like Japanese tokenizer does,  Nori need an option to preserve decimal point.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8784) Nori(Korean) tokenizer removes the decimal point.

2019-05-23 Thread Namgyu Kim (JIRA)


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

Namgyu Kim commented on LUCENE-8784:


Thank you for your reply, [~jim.ferenczi]!

Your approach looks awesome.
I developed KoreanNumberFilter by referring to JapaneseNumberFilter.
Please check my patch :D
(use "git apply --whitespace=fix LUCENE-8784.patch" because of trailing 
whitespace error :()

I did not set KoreanNumberFilter as the default filter in KoreanAnalyzer.
By the way, would not it be better to leave the constructors that do not use 
discardPunctuation parameters?
(Existing Nori users have to modify the code after uploading)


>  Nori(Korean) tokenizer removes the decimal point. 
> ---
>
> Key: LUCENE-8784
> URL: https://issues.apache.org/jira/browse/LUCENE-8784
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Munkyu Im
>Priority: Major
> Attachments: LUCENE-8784.patch, LUCENE-8784.patch, LUCENE-8784.patch
>
>
> This is the same issue that I mentioned to 
> [https://github.com/elastic/elasticsearch/issues/41401#event-2293189367]
> unlike standard analyzer, nori analyzer removes the decimal point.
> nori tokenizer removes "." character by default.
>  In this case, it is difficult to index the keywords including the decimal 
> point.
> It would be nice if there had the option whether add a decimal point or not.
> Like Japanese tokenizer does,  Nori need an option to preserve decimal point.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Reopened] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread Andrzej Bialecki (JIRA)


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

Andrzej Bialecki  reopened LUCENE-8809:
---

> Refresh and rollback concurrently can leave segment states unclosed
> ---
>
> Key: LUCENE-8809
> URL: https://issues.apache.org/jira/browse/LUCENE-8809
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 7.7, 8.1, 8.2
>Reporter: Nhat Nguyen
>Assignee: Nhat Nguyen
>Priority: Major
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.2
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
> Elasticsearch shows that refresh and rollback concurrently can leave segment 
> states unclosed leads to leaking refCount of some SegmentReaders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread Andrzej Bialecki (JIRA)


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

Andrzej Bialecki  commented on LUCENE-8809:
---

I just added a new (potential) version and reopened the issue. Once 8.1.1 is 
out you can commit this to the branch_8_1 and resolve it.

> Refresh and rollback concurrently can leave segment states unclosed
> ---
>
> Key: LUCENE-8809
> URL: https://issues.apache.org/jira/browse/LUCENE-8809
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 7.7, 8.1, 8.2
>Reporter: Nhat Nguyen
>Assignee: Nhat Nguyen
>Priority: Major
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.2
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
> Elasticsearch shows that refresh and rollback concurrently can leave segment 
> states unclosed leads to leaking refCount of some SegmentReaders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread Andrzej Bialecki (JIRA)


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

Andrzej Bialecki  updated LUCENE-8809:
--
Fix Version/s: 8.1.2

> Refresh and rollback concurrently can leave segment states unclosed
> ---
>
> Key: LUCENE-8809
> URL: https://issues.apache.org/jira/browse/LUCENE-8809
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 7.7, 8.1, 8.2
>Reporter: Nhat Nguyen
>Assignee: Nhat Nguyen
>Priority: Major
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.2
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
> Elasticsearch shows that refresh and rollback concurrently can leave segment 
> states unclosed leads to leaking refCount of some SegmentReaders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[GitHub] [lucene-solr] dnhatn commented on issue #684: LUCENE-8809: Ensure release segment states

2019-05-23 Thread GitBox
dnhatn commented on issue #684: LUCENE-8809: Ensure release segment states
URL: https://github.com/apache/lucene-solr/pull/684#issuecomment-495286439
 
 
   @martin-g @s1monw Thanks for reviewing.


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] dnhatn closed pull request #684: LUCENE-8809: Ensure release segment states

2019-05-23 Thread GitBox
dnhatn closed pull request #684: LUCENE-8809: Ensure release segment states
URL: https://github.com/apache/lucene-solr/pull/684
 
 
   


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] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread Nhat Nguyen (JIRA)


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

Nhat Nguyen resolved LUCENE-8809.
-
   Resolution: Fixed
 Assignee: Nhat Nguyen
Fix Version/s: 8.2
   master (9.0)
   7.7.2

We need to commit this fix to 8_1 after the releasing of 8.1.1 completed.

> Refresh and rollback concurrently can leave segment states unclosed
> ---
>
> Key: LUCENE-8809
> URL: https://issues.apache.org/jira/browse/LUCENE-8809
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 7.7, 8.1, 8.2
>Reporter: Nhat Nguyen
>Assignee: Nhat Nguyen
>Priority: Major
> Fix For: 7.7.2, master (9.0), 8.2
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
> Elasticsearch shows that refresh and rollback concurrently can leave segment 
> states unclosed leads to leaking refCount of some SegmentReaders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread ASF subversion and git services (JIRA)


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

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

Commit 4d5edca3e32a6b892b8af12186a37095c53e2793 in lucene-solr's branch 
refs/heads/branch_7x from Nhat Nguyen
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4d5edca ]

LUCENE-8809: Ensure release segment states

If refresh and rollback happen concurrently, then we can leave segment
states unreleased leads to leaking refCount of some SegmentReaders.


> Refresh and rollback concurrently can leave segment states unclosed
> ---
>
> Key: LUCENE-8809
> URL: https://issues.apache.org/jira/browse/LUCENE-8809
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 7.7, 8.1, 8.2
>Reporter: Nhat Nguyen
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
> Elasticsearch shows that refresh and rollback concurrently can leave segment 
> states unclosed leads to leaking refCount of some SegmentReaders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread ASF subversion and git services (JIRA)


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

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

Commit 1883cc9ea379c9c14973ae090518336e3179ab8b in lucene-solr's branch 
refs/heads/branch_7_7 from Nhat Nguyen
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1883cc9 ]

LUCENE-8809: Ensure release segment states

If refresh and rollback happen concurrently, then we can leave segment
states unreleased leads to leaking refCount of some SegmentReaders.


> Refresh and rollback concurrently can leave segment states unclosed
> ---
>
> Key: LUCENE-8809
> URL: https://issues.apache.org/jira/browse/LUCENE-8809
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 7.7, 8.1, 8.2
>Reporter: Nhat Nguyen
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
> Elasticsearch shows that refresh and rollback concurrently can leave segment 
> states unclosed leads to leaking refCount of some SegmentReaders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



Re: Lucene/Solr 8.1.1

2019-05-23 Thread Andrzej Białecki
Hi all,

A quick reminder that during the release process for 8.1.1 any commits to 
branch_8_1 must first be submitted as a patch in JIRA and approved by the 
release manager (yours truly).

—

Andrzej Białecki



[jira] [Commented] (SOLR-13434) OpenTracing support for Solr

2019-05-23 Thread Cao Manh Dat (JIRA)


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

Cao Manh Dat commented on SOLR-13434:
-

Sorry for the mess of gitbox. I was accidentally pushed the branch to origin 
instead of the cloned one (was quite sleepy)

> OpenTracing support for Solr
> 
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and 
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger, 
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing 
> APIs. Ideally, we can implement it once and have integrations for popular 
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack 
> of activity so this is a fresh attempt at solving this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread ASF subversion and git services (JIRA)


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

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

Commit af3be2b855c5bd7b3b5413ae4bf0ef89f9f7ef47 in lucene-solr's branch 
refs/heads/branch_8_1 from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=af3be2b ]

Revert "LUCENE-8809: Ensure release segment states"

This reverts commit 2e16009197ac10149a53eb97e875f89bd3a75472.


> Refresh and rollback concurrently can leave segment states unclosed
> ---
>
> Key: LUCENE-8809
> URL: https://issues.apache.org/jira/browse/LUCENE-8809
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 7.7, 8.1, 8.2
>Reporter: Nhat Nguyen
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
> Elasticsearch shows that refresh and rollback concurrently can leave segment 
> states unclosed leads to leaking refCount of some SegmentReaders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread Andrzej Bialecki (JIRA)


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

Andrzej Bialecki  commented on LUCENE-8809:
---

[~dnhatn] branch_8_1 is currently in lockdown due to the ongoing release 
process for 8.1.1. Please revert this commit from this branch.

> Refresh and rollback concurrently can leave segment states unclosed
> ---
>
> Key: LUCENE-8809
> URL: https://issues.apache.org/jira/browse/LUCENE-8809
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 7.7, 8.1, 8.2
>Reporter: Nhat Nguyen
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
> Elasticsearch shows that refresh and rollback concurrently can leave segment 
> states unclosed leads to leaking refCount of some SegmentReaders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



Re: [jira] [Commented] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread Nhat Nguyen
Hi Andrzej,

Please revert that commit. Thank you!

Nhat

> On May 23, 2019, at 11:59 AM, Andrzej Białecki  wrote:
> 
> Hi Nhat,
> 
> Commits to branch_8_1 are not allowed now due to the fact that this branch is 
> used for the 8.1.1 release - any critical bug fixes should be first submitted 
> to JIRA as a patch and approved by the release coordinator (in this case me). 
> Please revert your latest commit from branch_8_1.
> 
> 
> 
>> On 23 May 2019, at 17:51, ASF subversion and git services (JIRA) 
>>  wrote:
>> 
>> 
>>   [ 
>> https://issues.apache.org/jira/browse/LUCENE-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846812#comment-16846812
>>  ] 
>> 
>> ASF subversion and git services commented on LUCENE-8809:
>> -
>> 
>> Commit 2e16009197ac10149a53eb97e875f89bd3a75472 in lucene-solr's branch 
>> refs/heads/branch_8_1 from Nhat Nguyen
>> [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2e16009 ]
>> 
>> LUCENE-8809: Ensure release segment states
>> 
>> If refresh and rollback happen concurrently, then we can leave segment
>> states unreleased leads to leaking refCount of some SegmentReaders.
>> 
>> 
>>> Refresh and rollback concurrently can leave segment states unclosed
>>> ---
>>> 
>>>   Key: LUCENE-8809
>>>   URL: https://issues.apache.org/jira/browse/LUCENE-8809
>>>   Project: Lucene - Core
>>>Issue Type: Bug
>>>Components: core/index
>>>  Affects Versions: 7.7, 8.1, 8.2
>>>  Reporter: Nhat Nguyen
>>>  Priority: Major
>>>Time Spent: 50m
>>> Remaining Estimate: 0h
>>> 
>>> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
>>> Elasticsearch shows that refresh and rollback concurrently can leave 
>>> segment states unclosed leads to leaking refCount of some SegmentReaders.
>> 
>> 
>> 
>> --
>> This message was sent by Atlassian JIRA
>> (v7.6.3#76005)
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 


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



[jira] [Comment Edited] (SOLR-13434) OpenTracing support for Solr

2019-05-23 Thread Cao Manh Dat (JIRA)


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

Cao Manh Dat edited comment on SOLR-13434 at 5/23/19 4:00 PM:
--

My initial patch for this one, almost finish, but I still meet some problem on 
adding a new module named jeagertracer-configurator in Solr (failed to run ant 
generate-maven-artifacts). 
Areas that this issue should cover
* A basic distributed tracing for SolrCloud (outbound communications) on 
queries and indexing, other things like tracing on Overseer operations or 
Collections APIs can be added later.
* A jaeger-contrib module so users can use Solr with Jaeger as backend
* In case of Datadog, the Tracer is injected through Javaagent, so this also 
needs be supported in this issue.


was (Author: caomanhdat):
My initial patch for this one, almost finish, but I still meet some problem on 
adding a new module named jeagertracer-configurator in Solr (failed to run ant 
generate-maven-artifacts). 

> OpenTracing support for Solr
> 
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and 
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger, 
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing 
> APIs. Ideally, we can implement it once and have integrations for popular 
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack 
> of activity so this is a fresh attempt at solving this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



Re: [jira] [Commented] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread Andrzej Białecki
Hi Nhat,

Commits to branch_8_1 are not allowed now due to the fact that this branch is 
used for the 8.1.1 release - any critical bug fixes should be first submitted 
to JIRA as a patch and approved by the release coordinator (in this case me). 
Please revert your latest commit from branch_8_1.



> On 23 May 2019, at 17:51, ASF subversion and git services (JIRA) 
>  wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/LUCENE-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846812#comment-16846812
>  ] 
> 
> ASF subversion and git services commented on LUCENE-8809:
> -
> 
> Commit 2e16009197ac10149a53eb97e875f89bd3a75472 in lucene-solr's branch 
> refs/heads/branch_8_1 from Nhat Nguyen
> [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2e16009 ]
> 
> LUCENE-8809: Ensure release segment states
> 
> If refresh and rollback happen concurrently, then we can leave segment
> states unreleased leads to leaking refCount of some SegmentReaders.
> 
> 
>> Refresh and rollback concurrently can leave segment states unclosed
>> ---
>> 
>>Key: LUCENE-8809
>>URL: https://issues.apache.org/jira/browse/LUCENE-8809
>>Project: Lucene - Core
>> Issue Type: Bug
>> Components: core/index
>>   Affects Versions: 7.7, 8.1, 8.2
>>   Reporter: Nhat Nguyen
>>   Priority: Major
>> Time Spent: 50m
>> Remaining Estimate: 0h
>> 
>> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
>> Elasticsearch shows that refresh and rollback concurrently can leave segment 
>> states unclosed leads to leaking refCount of some SegmentReaders.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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



[jira] [Commented] (SOLR-13331) Atomic Update Multivalue remove does not work

2019-05-23 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski commented on SOLR-13331:


bq. It's not an abstraction. it is an optimization. We will not be a make 
changes confidently unless we have proper test coverage. 

Of course Noble.  I'm not trying to argue against improving the tests.  I'm 
trying to make the point that even with better tests, this BAUCS decision will 
be biting us for awhile, and we should consider other changes too.

Before the BAUCS change, devs didn't have to think about the wire-format at all 
while parsing requests.  Now the wire format matters.  So the BAUCS change has 
taken something that was relatively simple for devs and that happens a 
bazillion times in our codebase and it made it harder (or at least trappier).  
You, David, Thomas, and I all know about this problem now and we'll probably 
remember it the next time we write NamedList parsing code.  But the 200 or so 
other Solr contributors won't.  And the thousands of SolrJ users exposed to 
this definitely won't.  Mistakes are going to be made.

Improved test coverage will catch some of these issues.  And that's great.  But 
if we wake up tomorrow with a test base that randomizes the wire-format, and 
everything changed over to use it...our test coverage is still full of gaps.  
Issues are still going to get through.  Absolutely we should attend to our 
tests.  But it'd be foolish to not also reconsider the reason NamedList parsing 
code is now more difficult in the first place.

> Atomic Update Multivalue remove does not work
> -
>
> Key: SOLR-13331
> URL: https://issues.apache.org/jira/browse/SOLR-13331
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.7, 7.7.1, 8.0
> Environment: Standalone Solr Server
>Reporter: Thomas Wöckinger
>Assignee: Jason Gerlowski
>Priority: Critical
>  Labels: patch, pull-request-available, ready-to-commit, test
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, 
> SOLR-13331.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When using JavaBinCodec the values of collections are of type 
> ByteArrayUtf8CharSequence, existing field values are Strings so the remove 
> Operation does not have any effect.
> The relevant code is located in class AtomicUpdateDocumentMerger method 
> doRemove.
> The method parameter fieldVal contains the collection values of type 
> ByteArrayUtf8CharSequence, the variable original contains the collection of 
> Strings



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[GitHub] [lucene-solr] CaoManhDat commented on a change in pull request #685: SOLR-13434: OpenTracing support for Solr

2019-05-23 Thread GitBox
CaoManhDat commented on a change in pull request #685: SOLR-13434: OpenTracing 
support for Solr
URL: https://github.com/apache/lucene-solr/pull/685#discussion_r287016335
 
 

 ##
 File path: 
solr/contrib/jaegertracer-configurator/src/java/org/apache/solr/JaegerTracerConfigurator.java
 ##
 @@ -0,0 +1,91 @@
+/*
+ * 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.solr;
 
 Review comment:
   Is it a requirement? Since I like a sort clean name, it can be
   * org.apache.solr.JaegerTracerConfigurator
   * or org.apache.solr.jaeger.TracerConfigurator


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] CaoManhDat commented on a change in pull request #685: SOLR-13434: OpenTracing support for Solr

2019-05-23 Thread GitBox
CaoManhDat commented on a change in pull request #685: SOLR-13434: OpenTracing 
support for Solr
URL: https://github.com/apache/lucene-solr/pull/685#discussion_r287015718
 
 

 ##
 File path: solr/core/src/test/org/apache/solr/cloud/TestCloudRecovery.java
 ##
 @@ -64,7 +64,7 @@ public static void setupCluster() throws Exception {
 
   @Before
   public void beforeTest() throws Exception {
-configureCluster(2)
+configureCluster(4)
 
 Review comment:
   thanks, sorry for the confuse!


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-13454) Investigate ReindexCollectionTest failures

2019-05-23 Thread Erick Erickson (JIRA)


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

Erick Erickson resolved SOLR-13454.
---
   Resolution: Fixed
Fix Version/s: 8.2
   master (9.0)

Decided to commit this now instead, it's a trivial change.

> Investigate ReindexCollectionTest failures
> --
>
> Key: SOLR-13454
> URL: https://issues.apache.org/jira/browse/SOLR-13454
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: master (9.0), 8.2
>
>
> This _looks_ like it might be another example of commits not quite happening 
> correctly, see 
> SOLR-11035. Problem is I can’t get it to fail locally after 2,000 iterations.
> So I’m going to add a bit to the bandaid to allow tests to conditionally fail 
> if the bandaid would have made it pass. That way we can positively detect 
> that the bandaid is indeed the case rather than change code and hope.
> This _shouldn’t_ add any noise to the Jenkins lists, as the test won’t fail 
> in cases where it didn’t before.
> In case people wonder what the heck I’m doing.
> BTW, if we ever really understand/fix the underlying cause, we should make 
> the bandaid code fail and see, then remove it if so.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-13454) Investigate ReindexCollectionTest failures

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13454:


Commit 75f8ae55d04f4e6010587a7b001254997644ee83 in lucene-solr's branch 
refs/heads/branch_8x from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=75f8ae5 ]

SOLR-13454: Investigate ReindexCollectionTest failures

(cherry picked from commit 379e6f64b80918dd98a573c78be68fa901d70d5d)


> Investigate ReindexCollectionTest failures
> --
>
> Key: SOLR-13454
> URL: https://issues.apache.org/jira/browse/SOLR-13454
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> This _looks_ like it might be another example of commits not quite happening 
> correctly, see 
> SOLR-11035. Problem is I can’t get it to fail locally after 2,000 iterations.
> So I’m going to add a bit to the bandaid to allow tests to conditionally fail 
> if the bandaid would have made it pass. That way we can positively detect 
> that the bandaid is indeed the case rather than change code and hope.
> This _shouldn’t_ add any noise to the Jenkins lists, as the test won’t fail 
> in cases where it didn’t before.
> In case people wonder what the heck I’m doing.
> BTW, if we ever really understand/fix the underlying cause, we should make 
> the bandaid code fail and see, then remove it if so.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread ASF subversion and git services (JIRA)


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

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

Commit 2e16009197ac10149a53eb97e875f89bd3a75472 in lucene-solr's branch 
refs/heads/branch_8_1 from Nhat Nguyen
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2e16009 ]

LUCENE-8809: Ensure release segment states

If refresh and rollback happen concurrently, then we can leave segment
states unreleased leads to leaking refCount of some SegmentReaders.


> Refresh and rollback concurrently can leave segment states unclosed
> ---
>
> Key: LUCENE-8809
> URL: https://issues.apache.org/jira/browse/LUCENE-8809
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 7.7, 8.1, 8.2
>Reporter: Nhat Nguyen
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
> Elasticsearch shows that refresh and rollback concurrently can leave segment 
> states unclosed leads to leaking refCount of some SegmentReaders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[GitHub] [lucene-solr] CaoManhDat commented on a change in pull request #685: SOLR-13434: OpenTracing support for Solr

2019-05-23 Thread GitBox
CaoManhDat commented on a change in pull request #685: SOLR-13434: OpenTracing 
support for Solr
URL: https://github.com/apache/lucene-solr/pull/685#discussion_r287014145
 
 

 ##
 File path: 
solr/solrj/src/java/org/apache/solr/client/solrj/impl/Http2SolrClient.java
 ##
 @@ -452,23 +453,30 @@ private void setBasicAuthHeader(SolrRequest solrRequest, 
Request req) {
   private Request makeRequest(SolrRequest solrRequest, String collection)
   throws SolrServerException, IOException {
 Request req = createRequest(solrRequest, collection);
-req.header(HttpHeader.ACCEPT_ENCODING, null);
 
 Review comment:
   `decorateRequest()` method was added to make sure the consistent for 
decorating a request between `initOutStream()` and normal `request()`


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-13434) OpenTracing support for Solr

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13434:


Commit 7f38ca08b460917a2019b8efcd325631a7bca0c7 in lucene-solr's branch 
refs/heads/jira/SOLR-13434 from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7f38ca0 ]

SOLR-13434: Revert back un-related changes to TestCloudRecovery


> OpenTracing support for Solr
> 
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and 
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger, 
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing 
> APIs. Ideally, we can implement it once and have integrations for popular 
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack 
> of activity so this is a fresh attempt at solving this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-13434) OpenTracing support for Solr

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13434:


Commit 7e981464efd0bf9884681d63eea58cb296986047 in lucene-solr's branch 
refs/heads/jira/SOLR-13434 from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7e98146 ]

SOLR-13434: Remove .DS_Store


> OpenTracing support for Solr
> 
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and 
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger, 
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing 
> APIs. Ideally, we can implement it once and have integrations for popular 
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack 
> of activity so this is a fresh attempt at solving this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-13454) Investigate ReindexCollectionTest failures

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13454:


Commit 379e6f64b80918dd98a573c78be68fa901d70d5d in lucene-solr's branch 
refs/heads/master from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=379e6f6 ]

SOLR-13454: Investigate ReindexCollectionTest failures


> Investigate ReindexCollectionTest failures
> --
>
> Key: SOLR-13454
> URL: https://issues.apache.org/jira/browse/SOLR-13454
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> This _looks_ like it might be another example of commits not quite happening 
> correctly, see 
> SOLR-11035. Problem is I can’t get it to fail locally after 2,000 iterations.
> So I’m going to add a bit to the bandaid to allow tests to conditionally fail 
> if the bandaid would have made it pass. That way we can positively detect 
> that the bandaid is indeed the case rather than change code and hope.
> This _shouldn’t_ add any noise to the Jenkins lists, as the test won’t fail 
> in cases where it didn’t before.
> In case people wonder what the heck I’m doing.
> BTW, if we ever really understand/fix the underlying cause, we should make 
> the bandaid code fail and see, then remove it if so.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-13434) OpenTracing support for Solr

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13434:


Commit 67d587e7f673f7212ff81d1d0b9007b44eebdfd4 in lucene-solr's branch 
refs/heads/jira/SOLR-13434 from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=67d587e ]

SOLR-13434: Add back JavaagentTracerConfigurator


> OpenTracing support for Solr
> 
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and 
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger, 
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing 
> APIs. Ideally, we can implement it once and have integrations for popular 
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack 
> of activity so this is a fresh attempt at solving this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-13434) OpenTracing support for Solr

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13434:


Commit ff59746decd9a0f03763b438a460198847759c86 in lucene-solr's branch 
refs/heads/jira/SOLR-13434 from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ff59746 ]

SOLR-13434: Upgrade README for Jaeger contrib module


> OpenTracing support for Solr
> 
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and 
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger, 
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing 
> APIs. Ideally, we can implement it once and have integrations for popular 
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack 
> of activity so this is a fresh attempt at solving this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-13434) OpenTracing support for Solr

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13434:


Commit a341ee35ff6a5122059f5251d6af5f6a3a53fd8b in lucene-solr's branch 
refs/heads/jira/SOLR-13434 from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a341ee3 ]

SOLR-13434: Remove unnecessary file


> OpenTracing support for Solr
> 
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and 
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger, 
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing 
> APIs. Ideally, we can implement it once and have integrations for popular 
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack 
> of activity so this is a fresh attempt at solving this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-13434) OpenTracing support for Solr

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13434:


Commit b90883e58860c903bdbd43c18fecef9da96fe467 in lucene-solr's branch 
refs/heads/jira/SOLR-13434 from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b90883e ]

SOLR-13434: Initial commit


> OpenTracing support for Solr
> 
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and 
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger, 
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing 
> APIs. Ideally, we can implement it once and have integrations for popular 
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack 
> of activity so this is a fresh attempt at solving this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread ASF subversion and git services (JIRA)


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

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

Commit 9c5c7a7e8d2f81d6fa7f73fc0cc0bc617e0d72c2 in lucene-solr's branch 
refs/heads/branch_8x from Nhat Nguyen
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9c5c7a7 ]

LUCENE-8809: Ensure release segment states

If refresh and rollback happen concurrently, then we can leave segment
states unreleased leads to leaking refCount of some SegmentReaders.


> Refresh and rollback concurrently can leave segment states unclosed
> ---
>
> Key: LUCENE-8809
> URL: https://issues.apache.org/jira/browse/LUCENE-8809
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 7.7, 8.1, 8.2
>Reporter: Nhat Nguyen
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
> Elasticsearch shows that refresh and rollback concurrently can leave segment 
> states unclosed leads to leaking refCount of some SegmentReaders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread ASF subversion and git services (JIRA)


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

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

Commit 0435348b29ba25b15b01cf0a99ed3df7c205f294 in lucene-solr's branch 
refs/heads/master from Nhat Nguyen
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0435348 ]

LUCENE-8809: Ensure release segment states

If refresh and rollback happen concurrently, then we can leave segment
states unreleased leads to leaking refCount of some SegmentReaders.


> Refresh and rollback concurrently can leave segment states unclosed
> ---
>
> Key: LUCENE-8809
> URL: https://issues.apache.org/jira/browse/LUCENE-8809
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 7.7, 8.1, 8.2
>Reporter: Nhat Nguyen
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
> Elasticsearch shows that refresh and rollback concurrently can leave segment 
> states unclosed leads to leaking refCount of some SegmentReaders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[GitHub] [lucene-solr] risdenk commented on a change in pull request #685: SOLR-13434: OpenTracing support for Solr

2019-05-23 Thread GitBox
risdenk commented on a change in pull request #685: SOLR-13434: OpenTracing 
support for Solr
URL: https://github.com/apache/lucene-solr/pull/685#discussion_r287003300
 
 

 ##
 File path: 
solr/solrj/src/java/org/apache/solr/client/solrj/impl/Http2SolrClient.java
 ##
 @@ -452,23 +453,30 @@ private void setBasicAuthHeader(SolrRequest solrRequest, 
Request req) {
   private Request makeRequest(SolrRequest solrRequest, String collection)
   throws SolrServerException, IOException {
 Request req = createRequest(solrRequest, collection);
-req.header(HttpHeader.ACCEPT_ENCODING, null);
 
 Review comment:
   I don't know the implications of moving the lines before/after 
`setListeners` into the renamed `decorateRequest`. Clearing the 
`ACCEPT_ENCODING` and adding `REQ_PRINCIPAL_KEY` changes the request?


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] risdenk commented on a change in pull request #685: SOLR-13434: OpenTracing support for Solr

2019-05-23 Thread GitBox
risdenk commented on a change in pull request #685: SOLR-13434: OpenTracing 
support for Solr
URL: https://github.com/apache/lucene-solr/pull/685#discussion_r287002163
 
 

 ##
 File path: solr/core/src/test/org/apache/solr/cloud/TestCloudRecovery.java
 ##
 @@ -64,7 +64,7 @@ public static void setupCluster() throws Exception {
 
   @Before
   public void beforeTest() throws Exception {
-configureCluster(2)
+configureCluster(4)
 
 Review comment:
   Looks like `TestCloudRecovery` changes are unrelated?


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] risdenk commented on a change in pull request #685: SOLR-13434: OpenTracing support for Solr

2019-05-23 Thread GitBox
risdenk commented on a change in pull request #685: SOLR-13434: OpenTracing 
support for Solr
URL: https://github.com/apache/lucene-solr/pull/685#discussion_r286997178
 
 

 ##
 File path: 
solr/contrib/jaegertracer-configurator/src/java/org/apache/solr/JaegerTracerConfigurator.java
 ##
 @@ -0,0 +1,91 @@
+/*
+ * 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.solr;
 
 Review comment:
   Should this be in its own package? I'm not familiar with other contribs.


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] risdenk commented on a change in pull request #685: SOLR-13434: OpenTracing support for Solr

2019-05-23 Thread GitBox
risdenk commented on a change in pull request #685: SOLR-13434: OpenTracing 
support for Solr
URL: https://github.com/apache/lucene-solr/pull/685#discussion_r286998055
 
 

 ##
 File path: 
solr/core/src/java/org/apache/solr/core/JavaagentTracerConfigurator.java
 ##
 @@ -0,0 +1,39 @@
+///*
 
 Review comment:
   File completely commented out?


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-13454) Investigate ReindexCollectionTest failures

2019-05-23 Thread Erick Erickson (JIRA)


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

Erick Erickson commented on SOLR-13454:
---

I'll commit this by this weekend with the flag set that enables the bandaid.

the bandaid code is set to fail anyway now to verify that at least some of the 
failures in this suite are the result of whatever underlies SOLR-11035 so I'll 
flip the flag to try to not fail.



> Investigate ReindexCollectionTest failures
> --
>
> Key: SOLR-13454
> URL: https://issues.apache.org/jira/browse/SOLR-13454
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> This _looks_ like it might be another example of commits not quite happening 
> correctly, see 
> SOLR-11035. Problem is I can’t get it to fail locally after 2,000 iterations.
> So I’m going to add a bit to the bandaid to allow tests to conditionally fail 
> if the bandaid would have made it pass. That way we can positively detect 
> that the bandaid is indeed the case rather than change code and hope.
> This _shouldn’t_ add any noise to the Jenkins lists, as the test won’t fail 
> in cases where it didn’t before.
> In case people wonder what the heck I’m doing.
> BTW, if we ever really understand/fix the underlying cause, we should make 
> the bandaid code fail and see, then remove it if so.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[GitHub] [lucene-solr] risdenk commented on issue #685: SOLR-13434: OpenTracing support for Solr

2019-05-23 Thread GitBox
risdenk commented on issue #685: SOLR-13434: OpenTracing support for Solr
URL: https://github.com/apache/lucene-solr/pull/685#issuecomment-495260379
 
 
   @CaoManhDat looks like there are a few `.DS_Store` files added by mistake.


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-SmokeRelease-master - Build # 1343 - Still Failing

2019-05-23 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1343/

No tests ran.

Build Log:
[...truncated 23472 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 2566 links (2099 relative) to 3378 anchors in 253 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] [Commented] (SOLR-13434) OpenTracing support for Solr

2019-05-23 Thread Cao Manh Dat (JIRA)


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

Cao Manh Dat commented on SOLR-13434:
-

Hi [~krisden] 
Sure I created a PR. 

> OpenTracing support for Solr
> 
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and 
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger, 
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing 
> APIs. Ideally, we can implement it once and have integrations for popular 
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack 
> of activity so this is a fresh attempt at solving this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[GitHub] [lucene-solr] CaoManhDat opened a new pull request #685: SOLR-13434: Initial commit

2019-05-23 Thread GitBox
CaoManhDat opened a new pull request #685: SOLR-13434: Initial commit
URL: https://github.com/apache/lucene-solr/pull/685
 
 
   


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-13434) OpenTracing support for Solr

2019-05-23 Thread Kevin Risden (JIRA)


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

Kevin Risden commented on SOLR-13434:
-

[~caomanhdat] - might be easier to review as a PR? Nothing wrong with patches 
just seems like a big change.

> OpenTracing support for Solr
> 
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and 
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger, 
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing 
> APIs. Ideally, we can implement it once and have integrations for popular 
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack 
> of activity so this is a fresh attempt at solving this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-NightlyTests-8.1 - Build # 35 - Still Unstable

2019-05-23 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.1/35/

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest.testSimple

Error Message:
Waiting for collection testSimple2 Timeout waiting to see state for 
collection=testSimple2 
:DocCollection(testSimple2//collections/testSimple2/state.json/23)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{  
 "range":"8000-",   "state":"active",   "replicas":{
 "core_node3":{   
"dataDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node3/data/", 
  "base_url":"https://127.0.0.1:39678/solr;,   
"node_name":"127.0.0.1:39678_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node3/data/tlog",
   "core":"testSimple2_shard1_replica_n1",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node5":{   
"dataDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node5/data/", 
  "base_url":"https://127.0.0.1:35884/solr;,   
"node_name":"127.0.0.1:35884_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node5/data/tlog",
   "core":"testSimple2_shard1_replica_n2",   
"shared_storage":"true",   "state":"down"}}}, "shard2":{   
"range":"0-7fff",   "state":"active",   "replicas":{ 
"core_node7":{   
"dataDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node7/data/", 
  "base_url":"https://127.0.0.1:39678/solr;,   
"node_name":"127.0.0.1:39678_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node7/data/tlog",
   "core":"testSimple2_shard2_replica_n4",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node8":{   
"dataDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node8/data/", 
  "base_url":"https://127.0.0.1:35884/solr;,   
"node_name":"127.0.0.1:35884_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node8/data/tlog",
   "core":"testSimple2_shard2_replica_n6",   
"shared_storage":"true",   "state":"down",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"true",   "nrtReplicas":"2",   "tlogReplicas":"0"} Live 
Nodes: [127.0.0.1:37563_solr, 127.0.0.1:39678_solr] Last available state: 
DocCollection(testSimple2//collections/testSimple2/state.json/23)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{  
 "range":"8000-",   "state":"active",   "replicas":{
 "core_node3":{   
"dataDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node3/data/", 
  "base_url":"https://127.0.0.1:39678/solr;,   
"node_name":"127.0.0.1:39678_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node3/data/tlog",
   "core":"testSimple2_shard1_replica_n1",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node5":{   
"dataDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node5/data/", 
  "base_url":"https://127.0.0.1:35884/solr;,   
"node_name":"127.0.0.1:35884_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node5/data/tlog",
   "core":"testSimple2_shard1_replica_n2",   
"shared_storage":"true",   "state":"down"}}}, "shard2":{   
"range":"0-7fff",   "state":"active",   "replicas":{ 
"core_node7":{   
"dataDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node7/data/", 
  "base_url":"https://127.0.0.1:39678/solr;,   
"node_name":"127.0.0.1:39678_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node7/data/tlog",
   "core":"testSimple2_shard2_replica_n4",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node8":{   
"dataDir":"hdfs://localhost:45564/solr_hdfs_home/testSimple2/core_node8/data/", 
  "base_url":"https://127.0.0.1:35884/solr;,   
"node_name":"127.0.0.1:35884_solr",   "type":"NRT",   
"force_set_state":"false",   

[jira] [Commented] (SOLR-13349) High CPU usage in Solr due to Java 8 bug

2019-05-23 Thread Cassandra Targett (JIRA)


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

Cassandra Targett commented on SOLR-13349:
--

Yes, 7.7.2 is coming very soon - within the next couple of weeks.

> High CPU usage in Solr due to Java 8 bug
> 
>
> Key: SOLR-13349
> URL: https://issues.apache.org/jira/browse/SOLR-13349
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-13349.patch
>
>
> We've had sporadic reports of high CPU usage in Solr 7. Lukas Weiss reported 
> a Java 8 bug that appears to be the root cause (I have not personally 
> verified), see: [https://bugs.openjdk.java.net/browse/JDK-8129861] e-mail 
> reproduced below:
> CommitTracker makes this call:
> Executors.newScheduledThreadPool(0, new 
> DefaultSolrThreadFactory("commitScheduler"));
> The supposition is that calling this with 1 will fix this (untested)
> [~ichattopadhyaya] This affects 6.6 and IIUC you're spinning a new version. 
> We'll need to verify and include this fix.
> [~jpountz] You're right. I first thought "naaah, it wouldn't be that far 
> back" but your question made me check, thanks!
> AFAICT, this is the only place in Solr/Lucene that uses zero.
> Using Java 9+ is another work-around.
> Anyone picking this up should port to 7.7 as well.
> e-mail from the user's list (many thanks to Lukas and Adam).
> Apologies, I can’t figure out how to reply to the Solr mailing list.
>  I just ran across the same high CPU usage issue. I believe it’’s caused by 
>  this commit which was introduced in Solr 7.7.0 
>  
> [https://github.com/apache/lucene-solr/commit/eb652b84edf441d8369f5188cdd5e3ae2b151434#diff-e54b251d166135a1afb7938cfe152bb5]
>  There is a bug in JDK versions <=8 where using 0 threads in the 
>  ScheduledThreadPool causes high CPU usage: 
>  [https://bugs.openjdk.java.net/browse/JDK-8129861]
>  Oddly, the latest version 
>  of solr/core/src/java/org/apache/solr/update/CommitTracker.java on 
>  master still uses 0 executors as the default. Presumably most everyone is 
>  using JDK 9 or greater which has the bug fixed, so they don’t experience 
>  the bug.
>  Feel free to relay this back to the mailing list.
>  Thanks,
>  Adam Guthrie
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Assigned] (SOLR-13434) OpenTracing support for Solr

2019-05-23 Thread Cao Manh Dat (JIRA)


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

Cao Manh Dat reassigned SOLR-13434:
---

  Assignee: Cao Manh Dat
Attachment: SOLR-13434.patch

My initial patch for this one, almost finish, but I still meet some problem on 
adding a new module named jeagertracer-configurator in Solr (failed to run ant 
generate-maven-artifacts). 

> OpenTracing support for Solr
> 
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and 
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger, 
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing 
> APIs. Ideally, we can implement it once and have integrations for popular 
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack 
> of activity so this is a fresh attempt at solving this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Created] (LUCENE-8810) Flattening of nested disjunctions does not take into account number of clause limitation of builder

2019-05-23 Thread JIRA
Mickaël Sauvée created LUCENE-8810:
--

 Summary: Flattening of nested disjunctions does not take into 
account number of clause limitation of builder
 Key: LUCENE-8810
 URL: https://issues.apache.org/jira/browse/LUCENE-8810
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
Affects Versions: 8.0
Reporter: Mickaël Sauvée
 Fix For: 8.1.1


In org.apache.lucene.search.BooleanQuery, at the end of the function 
rewrite(IndexReader reader), the query is rewritten to flatten nested 
disjunctions.

This does not take into account the limitation on the number of clauses in a 
builder (1024).
 In some circumstances, this limite can be reached, hence an exception is 
thrown.

Here is a unit test that highlight this.


{code:java}
  public void testFlattenInnerDisjunctionsWithMoreThan1024Terms() throws 
IOException {
IndexSearcher searcher = newSearcher(new MultiReader());

BooleanQuery.Builder builder1024 = new BooleanQuery.Builder();
for(int i = 0; i < 1024; i++) {
  builder1024.add(new TermQuery(new Term("foo", "bar-" + i)), Occur.SHOULD);
}
Query inner = builder1024.build();
Query query = new BooleanQuery.Builder()
.add(inner, Occur.SHOULD)
.add(new TermQuery(new Term("foo", "baz")), Occur.SHOULD)
.build();
searcher.rewrite(query);
  }
{code}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS-EA] Lucene-Solr-8.1-Windows (64bit/jdk-13-ea+18) - Build # 108 - Unstable!

2019-05-23 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Windows/108/
Java: 64bit/jdk-13-ea+18 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.impl.CloudSolrClientTest

Error Message:
ObjectTracker found 5 object(s) that were not released!!! [InternalHttpClient, 
MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, SolrCore] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.http.impl.client.InternalHttpClient  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:321)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:330)
  at 
org.apache.solr.handler.IndexFetcher.createHttpClient(IndexFetcher.java:230)  
at org.apache.solr.handler.IndexFetcher.(IndexFetcher.java:272)  at 
org.apache.solr.handler.ReplicationHandler.inform(ReplicationHandler.java:1224) 
 at 
org.apache.solr.cloud.ReplicateFromLeader.startReplication(ReplicateFromLeader.java:109)
  at 
org.apache.solr.cloud.ZkController.startReplicationFromLeader(ZkController.java:1307)
  at org.apache.solr.cloud.ZkController.register(ZkController.java:1202)  at 
org.apache.solr.cloud.ZkController.register(ZkController.java:1148)  at 
org.apache.solr.core.ZkContainer.lambda$registerInZk$0(ZkContainer.java:190)  
at org.apache.solr.core.ZkContainer.registerInZk(ZkContainer.java:222)  at 
org.apache.solr.core.CoreContainer.registerCore(CoreContainer.java:1086)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1248)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1148)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188)
  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:181)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  at java.base/java.lang.Thread.run(Thread.java:835)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:99)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:779)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:976)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1238)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1148)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188)
  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:181)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  at java.base/java.lang.Thread.run(Thread.java:835)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:368)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:747)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:976)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1238)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1148)  at 

[jira] [Updated] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread Nhat Nguyen (JIRA)


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

Nhat Nguyen updated LUCENE-8809:

Affects Version/s: 7.7

> Refresh and rollback concurrently can leave segment states unclosed
> ---
>
> Key: LUCENE-8809
> URL: https://issues.apache.org/jira/browse/LUCENE-8809
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 7.7, 8.1, 8.2
>Reporter: Nhat Nguyen
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
> Elasticsearch shows that refresh and rollback concurrently can leave segment 
> states unclosed leads to leaking refCount of some SegmentReaders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-Tests-master - Build # 3348 - Unstable

2019-05-23 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3348/

1 tests failed.
FAILED:  org.apache.solr.cloud.ReindexCollectionTest.testSameTargetReindexing

Error Message:
Solr11035BandAid failAnyway == true, would have successfully repaired the 
collection: 'sameTargetReindexing' extra info: 'ReindexCollectionTest.indexDocs'

Stack Trace:
java.lang.AssertionError: Solr11035BandAid failAnyway == true, would have 
successfully repaired the collection: 'sameTargetReindexing' extra info: 
'ReindexCollectionTest.indexDocs'
at 
__randomizedtesting.SeedInfo.seed([22F8EEFCDC9E742F:9781052BDBF8EC6B]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.SolrTestCaseJ4.Solr11035BandAid(SolrTestCaseJ4.java:3086)
at 
org.apache.solr.cloud.ReindexCollectionTest.indexDocs(ReindexCollectionTest.java:387)
at 
org.apache.solr.cloud.ReindexCollectionTest.testSameTargetReindexing(ReindexCollectionTest.java:155)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 

[jira] [Commented] (SOLR-13349) High CPU usage in Solr due to Java 8 bug

2019-05-23 Thread Simon Tunnat (JIRA)


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

Simon Tunnat commented on SOLR-13349:
-

Will there be a Solr patch version 7.7.2 for this bug?

> High CPU usage in Solr due to Java 8 bug
> 
>
> Key: SOLR-13349
> URL: https://issues.apache.org/jira/browse/SOLR-13349
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-13349.patch
>
>
> We've had sporadic reports of high CPU usage in Solr 7. Lukas Weiss reported 
> a Java 8 bug that appears to be the root cause (I have not personally 
> verified), see: [https://bugs.openjdk.java.net/browse/JDK-8129861] e-mail 
> reproduced below:
> CommitTracker makes this call:
> Executors.newScheduledThreadPool(0, new 
> DefaultSolrThreadFactory("commitScheduler"));
> The supposition is that calling this with 1 will fix this (untested)
> [~ichattopadhyaya] This affects 6.6 and IIUC you're spinning a new version. 
> We'll need to verify and include this fix.
> [~jpountz] You're right. I first thought "naaah, it wouldn't be that far 
> back" but your question made me check, thanks!
> AFAICT, this is the only place in Solr/Lucene that uses zero.
> Using Java 9+ is another work-around.
> Anyone picking this up should port to 7.7 as well.
> e-mail from the user's list (many thanks to Lukas and Adam).
> Apologies, I can’t figure out how to reply to the Solr mailing list.
>  I just ran across the same high CPU usage issue. I believe it’’s caused by 
>  this commit which was introduced in Solr 7.7.0 
>  
> [https://github.com/apache/lucene-solr/commit/eb652b84edf441d8369f5188cdd5e3ae2b151434#diff-e54b251d166135a1afb7938cfe152bb5]
>  There is a bug in JDK versions <=8 where using 0 threads in the 
>  ScheduledThreadPool causes high CPU usage: 
>  [https://bugs.openjdk.java.net/browse/JDK-8129861]
>  Oddly, the latest version 
>  of solr/core/src/java/org/apache/solr/update/CommitTracker.java on 
>  master still uses 0 executors as the default. Presumably most everyone is 
>  using JDK 9 or greater which has the bug fixed, so they don’t experience 
>  the bug.
>  Feel free to relay this back to the mailing list.
>  Thanks,
>  Adam Guthrie
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[GitHub] [lucene-solr] dnhatn commented on a change in pull request #684: LUCENE-8809: Ensure release segment states

2019-05-23 Thread GitBox
dnhatn commented on a change in pull request #684: LUCENE-8809: Ensure release 
segment states
URL: https://github.com/apache/lucene-solr/pull/684#discussion_r28690
 
 

 ##
 File path: lucene/core/src/test/org/apache/lucene/index/TestIndexWriter.java
 ##
 @@ -3730,4 +3733,50 @@ public void testFlushWhileStartingNewThreads() throws 
IOException, InterruptedEx
 dir.close();
   }
 
+  public void testRefreshAndRollbackConcurrently() throws Exception {
+Directory dir = newDirectory();
+IndexWriter w = new IndexWriter(dir, newIndexWriterConfig());
+AtomicBoolean stopped = new AtomicBoolean();
+Semaphore indexedDocs = new Semaphore(0);
+Thread indexer = new Thread(() -> {
+  while (stopped.get() == false) {
+try {
+  String id = Integer.toString(random().nextInt(100));
+  Document doc = new Document();
+  doc.add(new StringField("id", id, Field.Store.YES));
+  w.updateDocument(new Term("id", id), doc);
+  indexedDocs.release(1);
+} catch (IOException e) {
+  throw new AssertionError(e);
+} catch (AlreadyClosedException ignored) {
+  return;
+}
+  }
+});
+
+SearcherManager sm = new SearcherManager(w, new SearcherFactory());
+Thread refresher = new Thread(() -> {
+  while (stopped.get() == false) {
+try {
+  sm.maybeRefreshBlocking();
+} catch (IOException e) {
+  throw new AssertionError(e);
+} catch (AlreadyClosedException ignored) {
+  return;
+}
+  }
+});
+
+try {
+  indexer.start();
+  refresher.start();
+  indexedDocs.acquire(1 + random().nextInt(100));
+  w.rollback();
+} finally {
+  stopped.get();
 
 Review comment:
   It should be `stopped.set(true)`. Fixed in 
https://github.com/apache/lucene-solr/pull/684/commits/e266f26d7b3acb4fce961f4816cf46080c813570.
 Thanks for looking.


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] dnhatn commented on a change in pull request #684: LUCENE-8809: Ensure release segment states

2019-05-23 Thread GitBox
dnhatn commented on a change in pull request #684: LUCENE-8809: Ensure release 
segment states
URL: https://github.com/apache/lucene-solr/pull/684#discussion_r28690
 
 

 ##
 File path: lucene/core/src/test/org/apache/lucene/index/TestIndexWriter.java
 ##
 @@ -3730,4 +3733,50 @@ public void testFlushWhileStartingNewThreads() throws 
IOException, InterruptedEx
 dir.close();
   }
 
+  public void testRefreshAndRollbackConcurrently() throws Exception {
+Directory dir = newDirectory();
+IndexWriter w = new IndexWriter(dir, newIndexWriterConfig());
+AtomicBoolean stopped = new AtomicBoolean();
+Semaphore indexedDocs = new Semaphore(0);
+Thread indexer = new Thread(() -> {
+  while (stopped.get() == false) {
+try {
+  String id = Integer.toString(random().nextInt(100));
+  Document doc = new Document();
+  doc.add(new StringField("id", id, Field.Store.YES));
+  w.updateDocument(new Term("id", id), doc);
+  indexedDocs.release(1);
+} catch (IOException e) {
+  throw new AssertionError(e);
+} catch (AlreadyClosedException ignored) {
+  return;
+}
+  }
+});
+
+SearcherManager sm = new SearcherManager(w, new SearcherFactory());
+Thread refresher = new Thread(() -> {
+  while (stopped.get() == false) {
+try {
+  sm.maybeRefreshBlocking();
+} catch (IOException e) {
+  throw new AssertionError(e);
+} catch (AlreadyClosedException ignored) {
+  return;
+}
+  }
+});
+
+try {
+  indexer.start();
+  refresher.start();
+  indexedDocs.acquire(1 + random().nextInt(100));
+  w.rollback();
+} finally {
+  stopped.get();
 
 Review comment:
   It should be `stopped.set(true)`. Thanks for looking.


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] martin-g commented on a change in pull request #684: LUCENE-8809: Ensure release segment states

2019-05-23 Thread GitBox
martin-g commented on a change in pull request #684: LUCENE-8809: Ensure 
release segment states
URL: https://github.com/apache/lucene-solr/pull/684#discussion_r286918182
 
 

 ##
 File path: lucene/core/src/test/org/apache/lucene/index/TestIndexWriter.java
 ##
 @@ -3730,4 +3733,50 @@ public void testFlushWhileStartingNewThreads() throws 
IOException, InterruptedEx
 dir.close();
   }
 
+  public void testRefreshAndRollbackConcurrently() throws Exception {
+Directory dir = newDirectory();
+IndexWriter w = new IndexWriter(dir, newIndexWriterConfig());
+AtomicBoolean stopped = new AtomicBoolean();
+Semaphore indexedDocs = new Semaphore(0);
+Thread indexer = new Thread(() -> {
+  while (stopped.get() == false) {
+try {
+  String id = Integer.toString(random().nextInt(100));
+  Document doc = new Document();
+  doc.add(new StringField("id", id, Field.Store.YES));
+  w.updateDocument(new Term("id", id), doc);
+  indexedDocs.release(1);
+} catch (IOException e) {
+  throw new AssertionError(e);
+} catch (AlreadyClosedException ignored) {
+  return;
+}
+  }
+});
+
+SearcherManager sm = new SearcherManager(w, new SearcherFactory());
+Thread refresher = new Thread(() -> {
+  while (stopped.get() == false) {
+try {
+  sm.maybeRefreshBlocking();
+} catch (IOException e) {
+  throw new AssertionError(e);
+} catch (AlreadyClosedException ignored) {
+  return;
+}
+  }
+});
+
+try {
+  indexer.start();
+  refresher.start();
+  indexedDocs.acquire(1 + random().nextInt(100));
+  w.rollback();
+} finally {
+  stopped.get();
 
 Review comment:
   What is this doing here ?


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] dnhatn commented on issue #684: LUCENE-8809: Ensure release segment states

2019-05-23 Thread GitBox
dnhatn commented on issue #684: LUCENE-8809: Ensure release segment states
URL: https://github.com/apache/lucene-solr/pull/684#issuecomment-495198038
 
 
   @s1monw Can you please have a look? Thank you!


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] dnhatn opened a new pull request #684: LUCENE-8809: Ensure release segment states

2019-05-23 Thread GitBox
dnhatn opened a new pull request #684: LUCENE-8809: Ensure release segment 
states
URL: https://github.com/apache/lucene-solr/pull/684
 
 
   A [failed test](https://github.com/elastic/elasticsearch/issues/30290) from 
Elasticsearch shows that refresh and rollback concurrently can leave segment 
states unreleased leads to leaking refCount of some SegmentReaders.


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] [Created] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

2019-05-23 Thread Nhat Nguyen (JIRA)
Nhat Nguyen created LUCENE-8809:
---

 Summary: Refresh and rollback concurrently can leave segment 
states unclosed
 Key: LUCENE-8809
 URL: https://issues.apache.org/jira/browse/LUCENE-8809
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 8.1, 8.2
Reporter: Nhat Nguyen


A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
Elasticsearch shows that refresh and rollback concurrently can leave segment 
states unclosed leads to leaking refCount of some SegmentReaders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Comment Edited] (SOLR-13315) Possible SolrIndexSearcher leak through LogWatcher and FunctionScoreQuery

2019-05-23 Thread Yury Pakhomov (JIRA)


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

Yury Pakhomov edited comment on SOLR-13315 at 5/23/19 11:32 AM:


I thought that disabling Log4j2Watcher in solr.xml
 can be used as a temporary solution in case if you have no time to build solr 
from source code with patches.
 But this fix only solves searcher leak though Log4j2Watcher.
 Not long ago I have found another leak with FunctionScoreQuery.
 It looks pretty simple but it relatively hard to find.

If FunctionScoreQuery will be cached in any org.apache.solr.search.SolrCache 
then when new searcher will be opened and old SolrIndexSearcher will try to 
warm caches of newly opened searcher calling method 
org.apache.solr.search.SolrIndexSearcher#warm()

As a result reference to old searcher will be cached in new searcher.
 Also it seems that this warmed query will have not valid results as 
FunctionScoreQuery will be partially executed with new searcher and partially 
with old Searcher.

So it seems that if you are using 7.4 solr and FunctionScoreQuery you have to 
apply patch created by Alan Woodward. I have checked it and this patch prevents 
this leak through cache regeneration.

There are multiple *ValueSource classes
 and some of them have method
 public abstract *ValuesSource rewrite(IndexSearcher reader) throws IOException;

Reference for passed IndexSearcher should be used with care to avoid such 
situations. 
 Currently only 
org.apache.lucene.queries.function.ValueSource.WrappedDoubleValuesSource
 was affected but it was fixed. Maybe some java doc should be added to avoid 
such problems in future implementations.

Scroll to the right to see full picture.

!old_searcher_leak_through_cache_regeneration.png!  

 


was (Author: ypakhomov):
I thought that disabling Log4j2Watcher in solr.xml
 can be used as a temporary solution in case if you have no time to build solr 
from source code with patches.
 But this fix only solves searcher leak though Log4j2Watcher.
 Not long ago I have found another leak with FunctionScoreQuery.
 It looks pretty simple but it relatively hard to find.

If FunctionScoreQuery will be cached in any org.apache.solr.search.SolrCache 
then when new searcher will opened SolrIndexSearcher will try to warm caches of 
newly opened searcher calling method 
org.apache.solr.search.SolrIndexSearcher#warm()

As a result reference to old searcher will be cached in new searcher.
 Also it seems that this warmed query will have not valid results as 
FunctionScoreQuery will be partially executed with new searcher and partially 
with old Searcher.

So it seems that if you are using 7.4 solr and FunctionScoreQuery you have to 
apply patch created by Alan Woodward. I have checked it and this patch prevents 
this leak through cache regeneration.

There are multiple *ValueSource classes
 and some of them have method
 public abstract *ValuesSource rewrite(IndexSearcher reader) throws IOException;

Reference for passed IndexSearcher should be used with care to avoid such 
situations. 
 Currently only 
org.apache.lucene.queries.function.ValueSource.WrappedDoubleValuesSource
 was affected but it was fixed. Maybe some java doc should be added to avoid 
such problems in future implementations.

Scroll to the right to see full picture.

!old_searcher_leak_through_cache_regeneration.png!  

 

> Possible SolrIndexSearcher leak through LogWatcher and FunctionScoreQuery
> -
>
> Key: SOLR-13315
> URL: https://issues.apache.org/jira/browse/SOLR-13315
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.5
>Reporter: Yury Pakhomov
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-13315.patch, 
> old_searcher_leak_through_cache_regeneration.png, 
> path_to_gc_root_from_heap_dump.png
>
>
> Here is possible leak of SolrIndexSearcher. Which prevents unused searchers 
> to be reclaimed by gc.
> This problem was found after analyzing heap dump which was created before 
> Full GC.
> 1) Where unused ref to SolrIndexSearcher is stored.
> Log4j2Watcher implements LogWatcher
>  and has CircularList history inherited from LogWatcher
> In history we can store Log4jLogEvent which can hold ref to 
> ParameterizedMessage
>  and ParameterizedMessage stores refs to all arguments of event log. (here we 
> can store objects which are no longer in use directly or indirectly)
> 2) How SolrIndexSearcher can be indirectly reached through this log buffer.
> If during FunctionScoreQuery execution ExitingReaderException("The request 
> took too long to iterate over terms. Timeout: " ..) will be thrown this query 
> will be 

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

2019-05-23 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/269/
Java: 64bit/jdk1.8.0_201 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.ActionThrottleTest.testAZeroNanoTimeReturnInWait

Error Message:
994ms

Stack Trace:
java.lang.AssertionError: 994ms
at 
__randomizedtesting.SeedInfo.seed([25A7EA5604732300:E6CC1164B032DEE3]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.ActionThrottleTest.testAZeroNanoTimeReturnInWait(ActionThrottleTest.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 14507 lines...]
   [junit4] Suite: org.apache.solr.cloud.ActionThrottleTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.ActionThrottleTest_25A7EA5604732300-001\init-core-data-001
   [junit4]   2> 1997698 

Re: [JENKINS] Lucene-Solr-NightlyTests-7.7 - Build # 18 - Still Unstable

2019-05-23 Thread Dawid Weiss
Hmm... this looks serious, no?
D.

On Thu, May 23, 2019 at 2:27 AM Apache Jenkins Server
 wrote:
>
> Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.7/18/
>
> 1 tests failed.
> FAILED:  
> org.apache.lucene.index.TestConcurrentMergeScheduler.testFlushExceptions
>
> Error Message:
>
>
> Stack Trace:
> java.lang.AssertionError
> at 
> __randomizedtesting.SeedInfo.seed([730AC7E1D88016C6:C760943BD16080F2]:0)
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at 
> org.apache.lucene.index.TestConcurrentMergeScheduler.testFlushExceptions(TestConcurrentMergeScheduler.java:128)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
> at java.lang.Thread.run(Thread.java:748)
>
>
>
>
> Build Log:
> [...truncated 991 lines...]
>[junit4] Suite: org.apache.lucene.index.TestConcurrentMergeScheduler
>[junit4]   2> NOTE: download the large Jenkins line-docs file by running 
> 'ant get-jenkins-line-docs' in the lucene directory.
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestConcurrentMergeScheduler -Dtests.method=testFlushExceptions 
> -Dtests.seed=730AC7E1D88016C6 

[JENKINS] Lucene-Solr-Tests-7.7 - Build # 25 - Unstable

2019-05-23 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.7/25/

1 tests failed.
FAILED:  org.apache.solr.handler.TestSQLHandler.doTest

Error Message:
--> http://127.0.0.1:38661/doy/collection1_shard2_replica_n1:Failed to execute 
sqlQuery 'select id, field_i, str_s, field_i_p, field_f_p, field_d_p, field_l_p 
from collection1 where (text='()' OR text='') AND text='' order by 
field_i desc' against JDBC connection 'jdbc:calcitesolr:'. Error while 
executing SQL "select id, field_i, str_s, field_i_p, field_f_p, field_d_p, 
field_l_p from collection1 where (text='()' OR text='') AND text='' 
order by field_i desc": java.io.IOException: 
java.util.concurrent.ExecutionException: java.io.IOException: --> 
http://127.0.0.1:44528/doy/collection1_shard2_replica_n6/:id{type=string,properties=indexed,stored,sortMissingLast,uninvertible}
 must have DocValues to use this feature.

Stack Trace:
java.io.IOException: --> 
http://127.0.0.1:38661/doy/collection1_shard2_replica_n1:Failed to execute 
sqlQuery 'select id, field_i, str_s, field_i_p, field_f_p, field_d_p, field_l_p 
from collection1 where (text='()' OR text='') AND text='' order by 
field_i desc' against JDBC connection 'jdbc:calcitesolr:'.
Error while executing SQL "select id, field_i, str_s, field_i_p, field_f_p, 
field_d_p, field_l_p from collection1 where (text='()' OR text='') AND 
text='' order by field_i desc": java.io.IOException: 
java.util.concurrent.ExecutionException: java.io.IOException: --> 
http://127.0.0.1:44528/doy/collection1_shard2_replica_n6/:id{type=string,properties=indexed,stored,sortMissingLast,uninvertible}
 must have DocValues to use this feature.
at 
__randomizedtesting.SeedInfo.seed([4B2D624438FFAB12:EC69DAE05544B8AB]:0)
at 
org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:215)
at 
org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2617)
at 
org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:145)
at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1075)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1047)
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)

[GitHub] [lucene-solr] thomaswoeckinger commented on issue #665: Fixes SOLR-11841, SOLR-13331

2019-05-23 Thread GitBox
thomaswoeckinger commented on issue #665: Fixes SOLR-11841, SOLR-13331
URL: https://github.com/apache/lucene-solr/pull/665#issuecomment-495135896
 
 
   Push includes commit from #681, will rebase this PR after merge of #681 


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] thomaswoeckinger commented on issue #665: Fixes SOLR-11841, SOLR-13331, SOLR-13347

2019-05-23 Thread GitBox
thomaswoeckinger commented on issue #665: Fixes SOLR-11841, SOLR-13331, 
SOLR-13347
URL: https://github.com/apache/lucene-solr/pull/665#issuecomment-495130339
 
 
   Will update this PR when #681 is merged, so @noblepaul and @janhoy plz have 
a look


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-13381) Unexpected docvalues type SORTED_NUMERIC Exception when grouping by a PointField facet

2019-05-23 Thread Zhu JiaJun (JIRA)


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

Zhu JiaJun commented on SOLR-13381:
---

[~teny], my company uses lots of grouping search and faceting, the 
"TrieIntField" work for me on solr 7.7.1. [~boqin], yes, that's probably the 
same issue.

> Unexpected docvalues type SORTED_NUMERIC Exception when grouping by a 
> PointField facet
> --
>
> Key: SOLR-13381
> URL: https://issues.apache.org/jira/browse/SOLR-13381
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: faceting
>Affects Versions: 7.0, 7.6, 7.7, 7.7.1
> Environment: solr, solrcloud
>Reporter: Zhu JiaJun
>Priority: Major
> Attachments: SOLR-13381.patch
>
>
> Hey,
> I got an "Unexpected docvalues type SORTED_NUMERIC" exception when I perform 
> group facet on an IntPointField. Debugging into the source code, the cause is 
> that internally the docvalue type for PointField is "NUMERIC" (single value) 
> or "SORTED_NUMERIC" (multi value), while the TermGroupFacetCollector class 
> requires the facet field must have a "SORTED" or "SOTRTED_SET" docvalue type: 
> [https://github.com/apache/lucene-solr/blob/2480b74887eff01f729d62a57b415d772f947c91/lucene/grouping/src/java/org/apache/lucene/search/grouping/TermGroupFacetCollector.java#L313]
>  
> When I change schema for all int field to TrieIntField, the group facet then 
> work. Since internally the docvalue type for TrieField is SORTED (single 
> value) or SORTED_SET (multi value).
> Regarding that the "TrieField" is depreciated in Solr7, please help on this 
> grouping facet issue for PointField. I also commented this issue in SOLR-7495.
>  
> In addtional, all place of "${solr.tests.IntegerFieldType}" in the unit test 
> files seems to be using the "TrieintField", if change to "IntPointField", 
> some unit tests will fail, for example: 
> [https://github.com/apache/lucene-solr/blob/3de0b3671998cc9bc723d10f1b31ce48cbd4fa64/solr/core/src/test/org/apache/solr/request/SimpleFacetsTest.java#L417]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[GitHub] [lucene-solr] thomaswoeckinger commented on a change in pull request #665: Fixes SOLR-11841, SOLR-13331, SOLR-13347

2019-05-23 Thread GitBox
thomaswoeckinger commented on a change in pull request #665: Fixes SOLR-11841, 
SOLR-13331, SOLR-13347
URL: https://github.com/apache/lucene-solr/pull/665#discussion_r286842053
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/handler/loader/XMLLoader.java
 ##
 @@ -178,13 +183,12 @@ public void load(SolrQueryRequest req, SolrQueryResponse 
rsp, ContentStream stre
   final byte[] body = IOUtils.toByteArray(is);
   // TODO: The charset may be wrong, as the real charset is later
   // determined by the XML parser, the content-type is only used as a 
hint!
-  log.trace("body", new String(body, (charset == null) ?
-ContentStreamBase.DEFAULT_CHARSET : charset));
+  log.trace("body", new String(body, (charset == null) ? 
ContentStreamBase.DEFAULT_CHARSET : charset));
   IOUtils.closeQuietly(is);
   is = new ByteArrayInputStream(body);
 }
-parser = (charset == null) ?
-  inputFactory.createXMLStreamReader(is) : 
inputFactory.createXMLStreamReader(is, charset);
+parser = (charset == null) ? inputFactory.createXMLStreamReader(is)
 
 Review comment:
   As i mentioned above if you select next to last in the commit view, it is 
easy to review, formatting is done only in the last commit 


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] thomaswoeckinger commented on a change in pull request #665: Fixes SOLR-11841, SOLR-13331, SOLR-13347

2019-05-23 Thread GitBox
thomaswoeckinger commented on a change in pull request #665: Fixes SOLR-11841, 
SOLR-13331, SOLR-13347
URL: https://github.com/apache/lucene-solr/pull/665#discussion_r286842112
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/schema/BoolField.java
 ##
 @@ -97,10 +98,9 @@ public boolean incrementToken() throws IOException {
   if (done) return false;
   done = true;
   int ch = input.read();
-  if (ch==-1) return false;
+  if (ch == -1) return false;
   termAtt.copyBuffer(
-  ((ch=='t' || ch=='T' || ch=='1') ? TRUE_TOKEN : FALSE_TOKEN)
 
 Review comment:
   As i mentioned above if you select next to last in the commit view, it is 
easy to review, formatting is done only in the last commit 


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] thomaswoeckinger commented on issue #681: Fix SOLR-13347

2019-05-23 Thread GitBox
thomaswoeckinger commented on issue #681: Fix SOLR-13347
URL: https://github.com/apache/lucene-solr/pull/681#issuecomment-495128425
 
 
   > Nice. I'm afraid we cannot merge without a test in this PR. Could of 
course let this PR depend on #665 and thus only add the one test needed..
   
   Added unit test to prove functionality


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-SmokeRelease-8.1 - Build # 35 - Still Failing

2019-05-23 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.1/35/

No tests ran.

Build Log:
[...truncated 23881 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 2566 links (2099 relative) to 3375 anchors in 253 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/solr/build/solr-ref-guide/bare-bones-html/

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

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/solr/package/solr-8.1.1.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/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-8.1/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-8.1/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-8.1/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-8.1/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-8.1/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-8.1/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-8.1/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-8.1/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-8.1/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-8.1/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-8.1/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:

[GitHub] [lucene-solr] colings86 commented on issue #680: LUCENE-8803: Provide a FieldComparator to allow sorting by a feature from a FeatureField

2019-05-23 Thread GitBox
colings86 commented on issue #680: LUCENE-8803: Provide a FieldComparator to 
allow sorting by a feature from a FeatureField
URL: https://github.com/apache/lucene-solr/pull/680#issuecomment-495113492
 
 
   @jpountz I added an entry to CHANGES.txt, thanks for the reviews


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: [VOTE] Release Lucene/Solr 8.1.1 RC1

2019-05-23 Thread Dawid Weiss
+1

SUCCESS! [1:06:17.897069]

D.

On Thu, May 23, 2019 at 8:25 AM Martin Grigorov  wrote:
>
> Hi,
>
> +1
>
> P.S. May I suggest to add short instructions to the vote mail how to test the 
> new release in your application.
> E.g. for applications using Maven one needs to add the following to pom.xml 
> and to change the dependencies version to 8.1.1:
>
> 
>   
> Apache Lucene
> 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.1-RC1-revfcbe46c28cef11bc058779afba09521de1b19bef/lucene/maven/
> true
> false
>   
> 
>
> And similar for Gradle.
>
> I hope that this way more Lucene/Solr users (i.e. non-committers) can help 
> testing the release.
>
> Regards,
> Martin
>
> On Wed, May 22, 2019 at 8:53 PM Andrzej Białecki  wrote:
>>
>> Please vote for release candidate 1 for Lucene/Solr 8.1.1.
>>
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.1-RC1-revfcbe46c28cef11bc058779afba09521de1b19bef
>>
>> You can run the smoke tester directly with this command:
>>
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.1-RC1-revfcbe46c28cef11bc058779afba09521de1b19bef
>>
>>
>> Here's my +1
>> SUCCESS! [1:00:35.149875]
>>
>> —
>>
>> Andrzej Białecki
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

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



[jira] [Commented] (SOLR-13484) autoscaling/diagnostics APIshould be able to give diagnostics output from config pasted as a payload

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13484:


Commit 123850d708ccdfee3d671a4db04050f7495887a9 in lucene-solr's branch 
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=123850d ]

SOLR-13484: typo


> autoscaling/diagnostics APIshould be able to give diagnostics output from 
> config pasted as a payload
> 
>
> Key: SOLR-13484
> URL: https://issues.apache.org/jira/browse/SOLR-13484
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the diagnostics from 
> autoscaling configuration sent as a payload . T
> {code:javascript}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/diagnostics
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[GitHub] [lucene-solr] noblepaul opened a new pull request #683: SOLR-13484: CHANGES.txt

2019-05-23 Thread GitBox
noblepaul opened a new pull request #683: SOLR-13484: CHANGES.txt
URL: https://github.com/apache/lucene-solr/pull/683
 
 
   


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-13484) autoscaling/diagnostics APIshould be able to give diagnostics output from config pasted as a payload

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13484:


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

SOLR-13484: CHANGES.txt



> autoscaling/diagnostics APIshould be able to give diagnostics output from 
> config pasted as a payload
> 
>
> Key: SOLR-13484
> URL: https://issues.apache.org/jira/browse/SOLR-13484
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the diagnostics from 
> autoscaling configuration sent as a payload . T
> {code:javascript}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/diagnostics
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[GitHub] [lucene-solr] noblepaul merged pull request #683: SOLR-13484: CHANGES.txt

2019-05-23 Thread GitBox
noblepaul merged pull request #683: SOLR-13484: CHANGES.txt
URL: https://github.com/apache/lucene-solr/pull/683
 
 
   


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-13484) autoscaling/diagnostics APIshould be able to give diagnostics output from config pasted as a payload

2019-05-23 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-13484:


Commit b5ba41311d2cd3113878629da0958970a00e3fe9 in lucene-solr's branch 
refs/heads/jira/SOLR-13484 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b5ba413 ]

SOLR-13484: CHANGES


> autoscaling/diagnostics APIshould be able to give diagnostics output from 
> config pasted as a payload
> 
>
> Key: SOLR-13484
> URL: https://issues.apache.org/jira/browse/SOLR-13484
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the diagnostics from 
> autoscaling configuration sent as a payload . T
> {code:javascript}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/diagnostics
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



  1   2   >