[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11) - Build # 23453 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23453/
Java: 64bit/jdk-11 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.search.TestRecovery.stressLogReplay

Error Message:
mismatch: '58'!='59' @ response/numFound

Stack Trace:
java.lang.RuntimeException: mismatch: '58'!='59' @ response/numFound
at 
__randomizedtesting.SeedInfo.seed([DC3896CF417806E3:1996756696EE11A1]:0)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1015)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:962)
at 
org.apache.solr.search.TestRecovery.stressLogReplay(TestRecovery.java:181)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)




Build Log:
[...truncated 2076 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J2-20190103_063126_0017606208646988812526.syserr
   [junit4] >>> JVM J2 emitted unexpected 

[jira] [Commented] (SOLR-13099) Support a new type of unit 'WEEK ' for DateMathParser

[Haochao Zhuang (JIRA)]

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

Haochao Zhuang commented on SOLR-13099:
---

Yes, I also think this will be complicated, so I set it to start from Sunday.


But sometimes we need to calculate the natural week. In this case so +7DAY gap 
is not that suitable for us。

> Support a new type of unit 'WEEK ' for DateMathParser
> -
>
> Key: SOLR-13099
> URL: https://issues.apache.org/jira/browse/SOLR-13099
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Haochao Zhuang
>Priority: Major
> Attachments: DateMathParser.java, DateMathParserTest.java
>
>
> for convenience purpose, i think a WEEK unit is necessary.



--
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-13099) Support a new type of unit 'WEEK ' for DateMathParser

[Haochao Zhuang (JIRA)]

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

Haochao Zhuang updated SOLR-13099:
--
Attachment: DateMathParserTest.java
DateMathParser.java

> Support a new type of unit 'WEEK ' for DateMathParser
> -
>
> Key: SOLR-13099
> URL: https://issues.apache.org/jira/browse/SOLR-13099
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Haochao Zhuang
>Priority: Major
> Attachments: DateMathParser.java, DateMathParserTest.java
>
>
> for convenience purpose, i think a WEEK unit is necessary.



--
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-7.x-Windows (64bit/jdk-12-ea+23) - Build # 939 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/939/
Java: 64bit/jdk-12-ea+23 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testClassifyStream

Error Message:
expected:<0.0> but was:<0.9998245650830389>

Stack Trace:
java.lang.AssertionError: expected:<0.0> but was:<0.9998245650830389>
at 
__randomizedtesting.SeedInfo.seed([794457C7994742DD:DC0CCDFFA01F5B49]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 
org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testClassifyStream(StreamDecoratorTest.java:3406)
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 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)




Build Log:
[...truncated 16209 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.io.stream.StreamDecoratorTest
   [junit4]   2> 

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 421 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/421/

2 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:42870/ze/p/forceleader_test_collection

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:42870/ze/p/forceleader_test_collection
at 
__randomizedtesting.SeedInfo.seed([7A2C2170CC9B1549:9CBB15B0F519EC28]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:484)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:414)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1110)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:504)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:479)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:294)
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:1063)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1035)
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 

[jira] [Commented] (SOLR-13100) harden/manage connectionpool used for intra-cluster communication when we know nodes go down

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-13100:


You might be able to - I mention that more of the impl is internal now because 
I think I worked around this when we did some of the impl and how I did it then 
doesn't work now.

You may be able to tie invalidating the right connections when someone leaves 
live nodes for 7x without much of a race, but I'm not sure if it's as 
straightforward as it seems.

 

 

> harden/manage connectionpool used for intra-cluster communication when we 
> know nodes go down
> 
>
> Key: SOLR-13100
> URL: https://issues.apache.org/jira/browse/SOLR-13100
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Major
>
> I'm spinng this idea off of some comments i made in SOLR-13028...
> In that issue, in discussion of some test failures that can happen after a 
> node is shutdown/restarted (new emphasis added)...
> {quote}
> The bit where the test fails is that it:
> # shuts down a jetty instance
> # starts the jetty instance again
> # does some waiting for all the collections to be "active" and all the 
> replicas to be "live"
> # tries to send an auto-scalling 'set-cluster-preferences' config change to 
> the cluster
> The bit of test code where it does this creates an entirely new 
> CLoudSolrClient, ignoring the existing one except for the ZKServer address, 
> w/an explicit comment that the reason it's doing this is because the 
> connection pool on the existing CloudSolrClient might have a stale connection 
> to the old (Ie: dead) instance of the restarted jetty...
>   ...
> ...doing this ensures that the cloudClient doesn't try to query the "dead" 
> server directly (on a stale connection) but IIUC this issue of stale 
> connections to the dead server instance is still problematic - and the root 
> cause of this failure - because after the CloudSolrClient picks a random node 
> to send the request to, _on the remote solr side, that node then has to 
> dispatch a request to each and every node, and at that point the node doing 
> the distributed dispatch may also have a stale connection pool pointing at a 
> server instance that's no longer listening._
> {quote}
> *The point of this issue is to explore, if/how we can -- in general -- better 
> deal with pooled connections in situations where the cluster state knows that 
> an existing node has gone down, or been restarted.*
> SOLR-13028 is a particular example of when/how stale pooled conection info 
> can cause test problems -- and the bulk of the discussion in that issue is 
> about how that specific code path (in dealing with an intra-cl autoscaling 
> handler command dispatch) can be improved to do a retry in the event of 
> NoHttpResponseException -- but not ever place where solr nodes need to talk 
> to each other can blindly retry on every possible connection exception; and 
> even when we can, it would be better if we could minimize the risk of the 
> request failing in a way that would require a retry.
> *So why not improve our HTTP connection pool to be aware of our clusterstate 
> and purge connections when we know odes have been shutdown/lost?*



--
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 # 2609 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/2609/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/251/consoleText

[repro] Revision: a1c6e642aad90d3615b4c71bf261a5aad7e32369

[repro] Repro line:  ant test  -Dtestcase=BasicAuthIntegrationTest 
-Dtests.seed=C5143895DF8F38D5 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=ca-ES -Dtests.timezone=Etc/GMT+10 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestSimLargeCluster 
-Dtests.method=testAddNode -Dtests.seed=C5143895DF8F38D5 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-ES 
-Dtests.timezone=Africa/Kigali -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestSimLargeCluster 
-Dtests.method=testNodeLost -Dtests.seed=C5143895DF8F38D5 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-ES 
-Dtests.timezone=Africa/Kigali -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestSimTriggerIntegration 
-Dtests.method=testNodeLostTriggerRestoreState -Dtests.seed=C5143895DF8F38D5 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=lt-LT -Dtests.timezone=Europe/Moscow -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
e5fda5d6f1cc6010e6b3565aa4bd70be31621692
[repro] git fetch
[repro] git checkout a1c6e642aad90d3615b4c71bf261a5aad7e32369

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

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

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   TestSimTriggerIntegration
[repro]   TestSimLargeCluster
[repro]   BasicAuthIntegrationTest
[repro] ant compile-test

[...truncated 3592 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.TestSimTriggerIntegration|*.TestSimLargeCluster|*.BasicAuthIntegrationTest"
 -Dtests.showOutput=onerror  -Dtests.seed=C5143895DF8F38D5 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=lt-LT 
-Dtests.timezone=Europe/Moscow -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[...truncated 26546 lines...]
   [junit4]   2> ERROR: Solr requires authentication for 
http://127.0.0.1:41794/solr/admin/info/system. Please supply valid credentials. 
HTTP code=401
   [junit4]   2> 
   [junit4]   2> 108708 ERROR 
(TEST-BasicAuthIntegrationTest.testBasicAuth-seed#[C5143895DF8F38D5]) [] 
o.a.s.s.BasicAuthIntegrationTest RunExampleTool failed due to: 
java.lang.NullPointerException; stdout from tool prior to failure: 
   [junit4]   2> 108740 ERROR 
(TEST-BasicAuthIntegrationTest.testBasicAuth-seed#[C5143895DF8F38D5]) [] 
o.a.s.c.s.i.CloudSolrClient Request to collection [authCollection] failed due 
to (401) org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
Error from server at http://127.0.0.1:44082/solr/authCollection: Expected mime 
type application/octet-stream but got text/html. 
   [junit4]   2> 
   [junit4]   2> 
   [junit4]   2> Error 401 require authentication
   [junit4]   2> 
   [junit4]   2> HTTP ERROR 401
   [junit4]   2> Problem accessing /solr/authCollection/select. Reason:
   [junit4]   2> require authenticationhttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.14.v20181114
   [junit4]   2> 
   [junit4]   2> 
   [junit4]   2> 
   [junit4]   2> , retry=0 commError=false errorCode=401 
   [junit4]   2> 108740 INFO  
(TEST-BasicAuthIntegrationTest.testBasicAuth-seed#[C5143895DF8F38D5]) [] 
o.a.s.c.s.i.CloudSolrClient request was not communication error it seems
   [junit4]   2> 108901 INFO  (qtp1978291675-163) [n:127.0.0.1:41794_solr] 
o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/info/key 
params={omitHeader=true=json} status=0 QTime=0
   [junit4]   2> 108901 INFO  (qtp1978291675-164) [n:127.0.0.1:41794_solr] 
o.a.s.s.PKIAuthenticationPlugin New Key obtained from  node: 
127.0.0.1:41794_solr / 
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm/mF6Dp4EqxO0JbcGBLzUT3ztszIfWz9PZs+0sGeikpykRsZM/EoXz0kj4pRLepSfA8f3A+seWrhay0d7T41BZGMYVNv3GIJLGDka3c5WjlOQ+N3cQTTr79OQs0YQBaIXpGRgAabr5kd8n7waqC29p/Z+bjCRN/5GSGtaH4c31VEpl9f6CVseKdyGVIlX51E6LnaDY76yUk29SiDKCMmxNDn+593DM7yl2iwIjciQkTDCMrn09zdbCqSGu2TpH6BRcrRaDmJ9RbcO+t+vyd8Byq29xq2lIpuDBnTU7D1CxgR4JHcm2KS4cYhaGxKABEarhUz9WgO8PIGxpHlpeXhCwIDAQAB
   [junit4]   2> 108948 INFO  (qtp89925652-152) [n:127.0.0.1:43122_solr 
c:authCollection s:shard3 r:core_node6 x:authCollection_shard3_replica_n3] 
o.a.s.c.S.Request [authCollection_shard3_replica_n3]  webapp=/solr path=/select 
params={df=text=false=id=score=4=0=true=http://127.0.0.1:43122/solr/authCollection_shard3_replica_n3/=10=2=*:*=1546485305933=true=javabin}
 hits=0 status=0 QTime=63
   [junit4]   2> 108952 INFO  

[jira] [Commented] (LUCENE-8621) Move LatLonShape out of sandbox

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-8621:


Ah. Thank you [~dsmiley]   I had forgotten about that issue.

+1 for the removal to be done for 8.0

> Move LatLonShape out of sandbox
> ---
>
> Key: LUCENE-8621
> URL: https://issues.apache.org/jira/browse/LUCENE-8621
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> LatLonShape has matured a lot over the last months, I'd like to start 
> thinking about moving it out of sandbox so that it doesn't stay there for too 
> long like what happened to LatLonPoint. I am pretty happy with the current 
> encoding. To my knowledge, we might just need to do a minor modification 
> because of 
> LUCENE-8620.



--
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-13106) Multiple mlt.fl does not work well if the termvectors is repeated

[luyi (JIRA)]

luyi created SOLR-13106:
---

 Summary: Multiple mlt.fl does not work well if the termvectors is 
repeated
 Key: SOLR-13106
 URL: https://issues.apache.org/jira/browse/SOLR-13106
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: MoreLikeThis
Affects Versions: 5.5.6
Reporter: luyi


for an example：

my data is：

{ "id":"100079750",

"title":" "I like cat, don't like dog",

"tags":["cat"],

"desc":["my cat photo"]

}

by the way title and desc's Tokenizer is IK.

and filed tags' type is text_ws.

while using mlt.fl=title,tags,desc with parameters debugQuery

the result shows：

"interestingTerms":[ "desc:my",1.0, "desc:photo",1.0, "desc:don",1.0, 
"title:dog",1.0, "desc:cat",1.0, "title:like",1.0],

"debug":{

"rawquerystring":"id:61",

"querystring":"id:61",

"parsedquery":"desc:my desc:photo desc:don title:dog desc:cat title:like", 
"parsedquery_toString":"desc:my desc:photo desc:don title:dog desc:cat 
title:like",

..

look at the word cat

it appears in field tags, desc and title,

but the result shows  the word cat only used in field desc and was ignored in 
field tags and title.

Finally, I found the reason when the word is repeated in more than one field.It 
will only be used in one field to do the work.

otherwise sometimes word is only in field tags, but while doing the mlt, the 
word was shows as other field such as title or desc, in fact there is never 
appear in these fields!

 

 

 

 



--
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-SmokeRelease-7.x - Build # 417 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/417/

No tests ran.

Build Log:
[...truncated 23484 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 2458 links (2009 relative) to 3221 anchors in 247 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr-ref-guide/bare-bones-html/

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

package:

-unpack-solr-tgz:

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

[jira] [Updated] (SOLR-13105) Add data visualizations to all Math Expression user guide pages

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-13105:
--
Summary: Add data visualizations to all Math Expression user guide pages  
(was: Add data visualization to all Math Expression user guide pages)

> Add data visualizations to all Math Expression user guide pages
> ---
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
>
> Now that we can comprehensively visualize math expressions with Apache 
> Zeppelin all the examples in the Math Expressions user guide should contain 
> visualizations.



--
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-13105) Add data visualization to all Math Expression user guide pages

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-13105:
-

 Summary: Add data visualization to all Math Expression user guide 
pages
 Key: SOLR-13105
 URL: https://issues.apache.org/jira/browse/SOLR-13105
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


Now that we can comprehensively visualize math expressions with Apache Zeppelin 
all the examples in the Math Expressions user guide should contain 
visualizations.



--
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-13105) Add data visualization to all Math Expression user guide pages

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-13105:
-

Assignee: Joel Bernstein

> Add data visualization to all Math Expression user guide pages
> --
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
>
> Now that we can comprehensively visualize math expressions with Apache 
> Zeppelin all the examples in the Math Expressions user guide should contain 
> visualizations.



--
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-7.x - Build # 1181 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/1181/

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest

Error Message:
ObjectTracker found 2 object(s) that were not released!!! [SolrZkClient, 
ZkStateReader] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.cloud.SolrZkClient  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:203)  
at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:126)  at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:116)  at 
org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:306)  at 
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:160)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:399)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:827)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
  at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)  at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)  at 
org.apache.solr.client.solrj.impl.SolrClientCloudManager.request(SolrClientCloudManager.java:115)
  at 
org.apache.solr.cloud.autoscaling.SystemLogListener.onEvent(SystemLogListener.java:126)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:824)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:795)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers.lambda$add$4(ScheduledTriggers.java:303)
  at 
org.apache.solr.cloud.autoscaling.NodeLostTrigger.run(NodeLostTrigger.java:185) 
 at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerWrapper.run(ScheduledTriggers.java:621)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.cloud.ZkStateReader  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:328)  
at 
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:160)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:399)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:827)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
  at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)  at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)  at 
org.apache.solr.client.solrj.impl.SolrClientCloudManager.request(SolrClientCloudManager.java:115)
  at 
org.apache.solr.cloud.autoscaling.SystemLogListener.onEvent(SystemLogListener.java:126)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:824)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:795)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers.lambda$add$4(ScheduledTriggers.java:303)
  at 
org.apache.solr.cloud.autoscaling.NodeLostTrigger.run(NodeLostTrigger.java:185) 
 at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerWrapper.run(ScheduledTriggers.java:621)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)   expected null, but 
was:(SolrZkClient.java:203)  
at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:126)  at 

[jira] [Resolved] (LUCENE-2073) Document issues involved in building your index with one jdk version and then searching/updating with another

[Steve Rowe (JIRA)]

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

Steve Rowe resolved LUCENE-2073.

Resolution: Fixed

> Document issues involved in building your index with one jdk version and then 
> searching/updating with another
> -
>
> Key: LUCENE-2073
> URL: https://issues.apache.org/jira/browse/LUCENE-2073
> Project: Lucene - Core
>  Issue Type: Task
>  Components: core/index
>Reporter: Mark Miller
>Assignee: Robert Muir
>Priority: Major
> Fix For: 6.0, 4.9
>
> Attachments: LUCENE-2073.patch, LUCENE-2073.patch, LUCENE-2073.patch, 
> LUCENE-2073.patch, stdAnalyzerTest.java
>
>
> I think this needs to go in something of a permenant spot - this isn't a one 
> time release type issues - its going to present over multiple release.
> {quote}
> If there is nothing we can do here, then we just have to do the best we can -
> such as a prominent notice alerting that if you transition JVM's between 
> building and searching the index and you are using or doing X, things will 
> break.
> We should put this in a spot that is always pretty visible - perhaps even a 
> new readme file titlted something like IndexBackwardCompatibility or 
> something, to which we can add other tips and gotchyas as they come up. Or 
> MaintainingIndicesAcrossVersions, or 
> FancyWhateverGetsYourAttentionAboutUpgradingStuff. Or a permanent 
> entry/sticky entry at the top of Changes.
> {quote}



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

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

[jira] [Resolved] (LUCENE-6102) regenerate bug

[Steve Rowe (JIRA)]

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

Steve Rowe resolved LUCENE-6102.

Resolution: Not A Problem

> regenerate bug
> --
>
> Key: LUCENE-6102
> URL: https://issues.apache.org/jira/browse/LUCENE-6102
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: 4.10.2
> Environment: PYTHON 2.6
> JDK 1.7.0.45
> ANT 1.9.2
>Reporter: Martin Gainty
>Priority: Major
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> 
> 
>
> 
> 
>   Running ${python.exe} on htmlentity.py
>   
> 
>  
>   
>file="src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex"
>  encoding="UTF-8"/>
> 
> 
> 
>   
>classpath="%ANT_HOME%/lib"/>
>   Run jflex-HTMLCharacterEntities
> 
> value="%LUCENE_HOME%/analysis/common/src/java/org/apache/lucene/analysis/standard"
>  />
>
> file="%LUCENE_HOME%/analysis/common/src/java/org/apache/lucene/charfilter/HTMLCharacterEntities.jflex"
>  outdir="%LUCENE_HOME%/analysis/common/src/java/org/apache/lucene/charfilter" 
> nobak="off" />
>   
> 
> when I regen'ed HTMLCharacterEntities.jflex I wanted to use jflex to generate 
> the HtmlCharacterEntitiesImpl.java file the above target 
> jflex-HTMLCharacterEntities will gen that file for you
> Nota Bene; take note of the bat/sh that properly sets PYTHONHOME and 
> PYTHONPATH so Python can locate subordinate .pyc components
> I also had to tweak Gerwin Kleins JFlex library from 2003 to take inputFile 
> and outputDir parameters
> Erik/Michael: does the original regenerate work for you?
> Martin Gainty 8 Dec 2014



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

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

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 251 - Unstable

[Apache Jenkins Server]

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

4 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testAddNode

Error Message:
no STARTED event

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


FAILED:  org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testNodeLost

Error Message:
no STARTED event: [], waitFor=5, killDelay=5000, minIgnored=0

Stack Trace:
java.lang.AssertionError: no STARTED event: [], waitFor=5, killDelay=5000, 
minIgnored=0
at 
__randomizedtesting.SeedInfo.seed([C5143895DF8F38D5:7A01F66B5C655D53]:0)
at 

[jira] [Reopened] (SOLR-13072) Management of markers for nodeLost / nodeAdded events is broken

[Hoss Man (JIRA)]

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

Hoss Man reopened SOLR-13072:
-

[~ab] - if you fixed the underlying problem (and updated 
{{NodeMarkersRegistrationTest}} to know about the new mechanism for dealing 
with these markers) then is there any reason why 
{{NodeMarkersRegistrationTest}} still needs the 
{{@AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/SOLR-13072;)}} I 
added when i created this issue?

Also: your commit seems to have caused 
{{TestSimTriggerIntegration.testNodeMarkersRegistration}} to start failing 
fairly reliably ... I'm guessing this is because with your changes the only 
thing that _should_ clear up these paths is the {{.scheduled_maintenance}} 
trigger's {{inactive_markers_plan}} action - but 
{{TestSimTriggerIntegration.setupTest()}} explicitly disables 
{{.scheduled_maintenance}} ... but there is also still code in 
OverseerTriggerThread that deals with these markers -- so frankly i'm not 
really sure what the "correct" behavior is...

{code}
  log.debug("-- cleaning old nodeLost / nodeAdded markers");
  removeMarkers(ZkStateReader.SOLR_AUTOSCALING_NODE_LOST_PATH);
  removeMarkers(ZkStateReader.SOLR_AUTOSCALING_NODE_ADDED_PATH);
{code}


> Management of markers for nodeLost / nodeAdded events is broken
> ---
>
> Key: SOLR-13072
> URL: https://issues.apache.org/jira/browse/SOLR-13072
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: 7.5, 7.6, master (8.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: master (8.0), 7.7
>
>
> In order to prevent {{nodeLost}} events from being lost when it's the 
> Overseer leader that is the node that was lost a mechanism was added to 
> record markers for these events by any other live node, in 
> {{ZkController.registerLiveNodesListener()}}. As similar mechanism also 
> exists for {{nodeAdded}} events.
> On Overseer leader restart if the autoscaling configuration didn't contain 
> any triggers that consume {{nodeLost}} events then these markers are removed. 
> If there are 1 or more trigger configs that consume {{nodeLost}} events then 
> these triggers would read the markers, remove them and generate appropriate 
> events.
> However, as the {{NodeMarkersRegistrationTest}} shows this mechanism is 
> broken and susceptible to race conditions.
> It's not unusual to have more than 1 {{nodeLost}} trigger because in addition 
> to any user-defined triggers there's always one that is automatically defined 
> if missing: {{.auto_add_replicas}}. However, if there's more than 1 
> {{nodeLost}} trigger then the process of consuming and removing the markers 
> becomes non-deterministic - each trigger may pick up (and delete) all, none, 
> or some of the markers.
> So as it is now this mechanism is broken if more than 1 {{nodeLost}} or more 
> than 1 {{nodeAdded}} trigger is defined.



--
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-13104) Add natural and repeat Stream Evaluators

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-13104:
--
Description: 
The *natural* Stream Evaluator returns a vector of natural numbers. This is 
useful for creating a sequence of numbers 0...N for plotting an x-axis.

Sample syntax:
{code:java}
let(a=natural(10)){code}
The *repeat* Stream Evaluator creates a vector with a number repeated N times. 
This useful for plotting a straight line.

Sample syntax:
{code:java}
let(a=repeat(5.5, 100)){code}

  was:
The natural Stream Evaluator returns a vector of natural numbers. This is 
useful for creating a sequence of numbers 0...N for plotting an x-axis.

Sample syntax:
{code:java}
let(a=natural(10)){code}
The repeat Stream Evaluator creates a vector with a number repeated N times. 
This useful for plotting a straight line.

Sample syntax:
{code:java}
let(a=repeat(5.5, 100)){code}


> Add natural and repeat Stream Evaluators
> 
>
> Key: SOLR-13104
> URL: https://issues.apache.org/jira/browse/SOLR-13104
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
>
> The *natural* Stream Evaluator returns a vector of natural numbers. This is 
> useful for creating a sequence of numbers 0...N for plotting an x-axis.
> Sample syntax:
> {code:java}
> let(a=natural(10)){code}
> The *repeat* Stream Evaluator creates a vector with a number repeated N 
> times. This useful for plotting a straight line.
> Sample syntax:
> {code:java}
> let(a=repeat(5.5, 100)){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] [Updated] (SOLR-13104) Add natural and repeat Stream Evaluators

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-13104:
--
Description: 
The natural Stream Evaluator returns a vector of natural numbers. This is 
useful for creating a sequence of numbers 0...N for plotting an x-axis.

Sample syntax:
{code:java}
let(a=natural(10)){code}
The repeat Stream Evaluator creates a vector with a number repeated N times. 
This useful for plotting a straight line.

Sample syntax:
{code:java}
let(a=repeat(5.5, 100)){code}

  was:
The natural Stream Evaluator returns a vector of natural numbers. This is 
useful for creating a sequence of numbers 0...N for plotting an x-axis.

Sample syntax:
{code:java}
let(a=natural(10)){code}


> Add natural and repeat Stream Evaluators
> 
>
> Key: SOLR-13104
> URL: https://issues.apache.org/jira/browse/SOLR-13104
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
>
> The natural Stream Evaluator returns a vector of natural numbers. This is 
> useful for creating a sequence of numbers 0...N for plotting an x-axis.
> Sample syntax:
> {code:java}
> let(a=natural(10)){code}
> The repeat Stream Evaluator creates a vector with a number repeated N times. 
> This useful for plotting a straight line.
> Sample syntax:
> {code:java}
> let(a=repeat(5.5, 100)){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] [Updated] (SOLR-13104) Add natural and repeat Stream Evaluators

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-13104:
--
Summary: Add natural and repeat Stream Evaluators  (was: Add natural Stream 
Evaluator)

> Add natural and repeat Stream Evaluators
> 
>
> Key: SOLR-13104
> URL: https://issues.apache.org/jira/browse/SOLR-13104
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
>
> The natural Stream Evaluator returns a vector of natural numbers. This is 
> useful for creating a sequence of numbers 0...N for plotting an x-axis.
> Sample syntax:
> {code:java}
> let(a=natural(10)){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] [Assigned] (SOLR-13104) Add natural Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-13104:
-

Assignee: Joel Bernstein

> Add natural Stream Evaluator
> 
>
> Key: SOLR-13104
> URL: https://issues.apache.org/jira/browse/SOLR-13104
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
>
> The natural Stream Evaluator returns a vector of natural numbers. This is 
> useful for creating a sequence of numbers 0...N for plotting an x-axis.
> Sample syntax:
> {code:java}
> let(a=natural(10)){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] [Created] (SOLR-13104) Add natural Stream Evaluator

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-13104:
-

 Summary: Add natural Stream Evaluator
 Key: SOLR-13104
 URL: https://issues.apache.org/jira/browse/SOLR-13104
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


The natural Stream Evaluator returns a vector of natural numbers. This is 
useful for creating a sequence of numbers 0...N for plotting an x axis.

Sample syntax:
{code:java}
let(a=natural(10)){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] [Updated] (SOLR-13104) Add natural Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-13104:
--
Description: 
The natural Stream Evaluator returns a vector of natural numbers. This is 
useful for creating a sequence of numbers 0...N for plotting an x-axis.

Sample syntax:
{code:java}
let(a=natural(10)){code}

  was:
The natural Stream Evaluator returns a vector of natural numbers. This is 
useful for creating a sequence of numbers 0...N for plotting an x axis.

Sample syntax:
{code:java}
let(a=natural(10)){code}


> Add natural Stream Evaluator
> 
>
> Key: SOLR-13104
> URL: https://issues.apache.org/jira/browse/SOLR-13104
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Priority: Major
>
> The natural Stream Evaluator returns a vector of natural numbers. This is 
> useful for creating a sequence of numbers 0...N for plotting an x-axis.
> Sample syntax:
> {code:java}
> let(a=natural(10)){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] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_172) - Build # 3330 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/3330/
Java: 32bit/jdk1.8.0_172 -server -XX:+UseParallelGC

7 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testAddNode

Error Message:
no STARTED event

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


FAILED:  org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testAddNode

Error Message:
no STARTED event

Stack Trace:
java.lang.AssertionError: no STARTED event
at 
__randomizedtesting.SeedInfo.seed([11B6C146C1B2B355:B659DCE50EFF3C4D]:0)
at org.junit.Assert.fail(Assert.java:88)
at 

[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk1.8.0) - Build # 1005 - Still Unstable!

[Policeman Jenkins Server]

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

8 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testAddNode

Error Message:
no STARTED event

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


FAILED:  org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testAddNode

Error Message:
no STARTED event

Stack Trace:
java.lang.AssertionError: no STARTED event
at 
__randomizedtesting.SeedInfo.seed([6BDC2815ED9D7077:CC3335B622D0FF6F]:0)
at org.junit.Assert.fail(Assert.java:88)
 

[jira] [Commented] (SOLR-13045) Harden TestSimPolicyCloud

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-13045:


fucit.org reports zero failures in the past week, so I think we can call this 
done.  I'm going to backport the fixes to branch_7_6 tonight, in case there's 
interest in a 7.6.1 at some point, and then I'll be closing this out.

> Harden TestSimPolicyCloud
> -
>
> Key: SOLR-13045
> URL: https://issues.apache.org/jira/browse/SOLR-13045
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13045.patch, SOLR-13045.patch, jenkins.log.txt.gz
>
>
> Several tests in TestSimPolicyCloud, but especially 
> {{testCreateCollectionAddReplica}}, have some flaky behavior, even after 
> Mark's recent test-fix commit.  This JIRA covers looking into and (hopefully) 
> fixing this test failure.



--
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-13100) harden/manage connectionpool used for intra-cluster communication when we know nodes go down

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-13100:
-

bq. ... otherwise it's done on a timer with a thread and somehow shutting down 
Jetty and starting it again does not play quite correctly with our stale 
connection avoidance strategy (try to make client manage the connection 
lifecycle instead of the server).

But in the case of nodes talking to other nodes, we control the client(s) *AND* 
the server(s) and (unless i'm missunderstanding something) every (solr) node 
has a zk watch on the {{live_node}} zkNode for every other (solr) node ... so 
why can't each solr X node invalidate it's connection pool if it see's node Y 
has gone away (or ideally just the pooled connections to node Y) ?

> harden/manage connectionpool used for intra-cluster communication when we 
> know nodes go down
> 
>
> Key: SOLR-13100
> URL: https://issues.apache.org/jira/browse/SOLR-13100
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Major
>
> I'm spinng this idea off of some comments i made in SOLR-13028...
> In that issue, in discussion of some test failures that can happen after a 
> node is shutdown/restarted (new emphasis added)...
> {quote}
> The bit where the test fails is that it:
> # shuts down a jetty instance
> # starts the jetty instance again
> # does some waiting for all the collections to be "active" and all the 
> replicas to be "live"
> # tries to send an auto-scalling 'set-cluster-preferences' config change to 
> the cluster
> The bit of test code where it does this creates an entirely new 
> CLoudSolrClient, ignoring the existing one except for the ZKServer address, 
> w/an explicit comment that the reason it's doing this is because the 
> connection pool on the existing CloudSolrClient might have a stale connection 
> to the old (Ie: dead) instance of the restarted jetty...
>   ...
> ...doing this ensures that the cloudClient doesn't try to query the "dead" 
> server directly (on a stale connection) but IIUC this issue of stale 
> connections to the dead server instance is still problematic - and the root 
> cause of this failure - because after the CloudSolrClient picks a random node 
> to send the request to, _on the remote solr side, that node then has to 
> dispatch a request to each and every node, and at that point the node doing 
> the distributed dispatch may also have a stale connection pool pointing at a 
> server instance that's no longer listening._
> {quote}
> *The point of this issue is to explore, if/how we can -- in general -- better 
> deal with pooled connections in situations where the cluster state knows that 
> an existing node has gone down, or been restarted.*
> SOLR-13028 is a particular example of when/how stale pooled conection info 
> can cause test problems -- and the bulk of the discussion in that issue is 
> about how that specific code path (in dealing with an intra-cl autoscaling 
> handler command dispatch) can be improved to do a retry in the event of 
> NoHttpResponseException -- but not ever place where solr nodes need to talk 
> to each other can blindly retry on every possible connection exception; and 
> even when we can, it would be better if we could minimize the risk of the 
> request failing in a way that would require a retry.
> *So why not improve our HTTP connection pool to be aware of our clusterstate 
> and purge connections when we know odes have been shutdown/lost?*



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

[Apache Jenkins Server]

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

No tests ran.

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

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

package:

-unpack-solr-tgz:

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

[jira] [Commented] (SOLR-13050) SystemLogListener can "lose" record of nodeLost event when node lost is/was .system collection leader

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13050:


Commit 1e735a1128256c4da7ebccd639a9d6579077aebe in lucene-solr's branch 
refs/heads/branch_7x from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1e735a1 ]

SOLR-13050: Fix the test so that .system events are collected again.


> SystemLogListener can "lose" record of nodeLost event when node lost is/was 
> .system collection leader
> -
>
> Key: SOLR-13050
> URL: https://issues.apache.org/jira/browse/SOLR-13050
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13050.test-workaround.patch, 
> jenkins.sarowe__Lucene-Solr-tests-7.x__7104.log.txt
>
>
> A chicken/egg issue of the way the autoscaling SystemLogListener uses the 
> {{.system}} collection to record event history is that in the case of a 
> {{nodeLost}} event for the {{.system}} collection's leader, there is a window 
> of time during leader election where trying to add the "Document" 
> representing that {{nodeLost}} event to the {{.system}} collection can fail.
> This isn't a silently failure: the SystemLogListener, acting the role of a 
> Solr client, is informed that the "add" failed, but it doesn't/can't do much 
> to deal with this situation other then to "log" (to the slf4j Logger) that it 
> wasn't able to add the doc.
> 
> I'm not sure how much of a "real world" impact this has on users, but I 
> noticed the issue while diagnosing a jenkins test failure and wanted to track 
> it.



--
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-13102) Shared storage Directory implementation

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-13102:

Description: 
We need a general strategy (and probably a general base class) that can work 
with shared storage and not corrupt indexes from multiple writers.

One strategy that is used on local disk is to use locks.  This doesn't extend 
well to remote / shared filesystems when the locking is not tied into the 
object store itself since a process can lose the lock (a long GC or whatever) 
and then immediately try to write a file and there is no way to stop it.

An alternate strategy ditches the use of locks and simply avoids overwriting 
files by some algorithmic mechanism.
One of my colleagues outlined one way to do this: 
https://www.youtube.com/watch?v=UeTFpNeJ1Fo
That strategy uses random looking filenames and then writes a "core.metadata" 
file that maps between the random names and the original names.  The problem is 
then reduced to overwriting "core.metadata" when you lose the lock.  One way to 
fix this is to version "core.metadata".  Since the new leader election code was 
implemented, each shard as a monotonically increasing "leader term", and we can 
use that as part of the filename.  When a reader goes to open an index, it can 
use the latest file from the directory listing, or even use the term obtained 
from ZK if we can't trust the directory listing to be up to date.  
Additionally, we don't need random filenames to avoid collisions... a simple 
unique prefix or suffix would work fine (such as the leader term again)



  was:
We need a general strategy (and probably a general base class) that can work 
with shared storage and not corrupt indexes from multiple writers.

One strategy that is used on local disk is to use locks.  This doesn't extend 
well to remote / shared filesystems when the locking is not tied into the 
object store itself since a process can lose the lock (a long GC or whatever) 
and then immediately try to write a file and there is no way to stop it.

An alternate strategy ditches the use of locks and simply avoids overwriting 
files by some algorithmic mechanism.
One of my colleagues outlined one way to do this: 
https://www.youtube.com/watch?v=UeTFpNeJ1Fo
That strategy uses random looking filenames and then writes a "core.metadata" 
file that maps between the random names and the original names.  The problem is 
then reduced to overwriting "core.metadata" when you lose the lock.  One way to 
fix this is to version "core.metadata".  Since the new leader election code was 
implemented, each shard as a monotonically increasing "leader term", and we can 
use that as part of the filename.  When a reader goes to open an index, it can 
use the latest file from the directory listing, or even use the term obtained 
from ZK if we can't trust the directory listing to be up to date.




> Shared storage Directory implementation
> ---
>
> Key: SOLR-13102
> URL: https://issues.apache.org/jira/browse/SOLR-13102
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Yonik Seeley
>Priority: Major
>
> We need a general strategy (and probably a general base class) that can work 
> with shared storage and not corrupt indexes from multiple writers.
> One strategy that is used on local disk is to use locks.  This doesn't extend 
> well to remote / shared filesystems when the locking is not tied into the 
> object store itself since a process can lose the lock (a long GC or whatever) 
> and then immediately try to write a file and there is no way to stop it.
> An alternate strategy ditches the use of locks and simply avoids overwriting 
> files by some algorithmic mechanism.
> One of my colleagues outlined one way to do this: 
> https://www.youtube.com/watch?v=UeTFpNeJ1Fo
> That strategy uses random looking filenames and then writes a "core.metadata" 
> file that maps between the random names and the original names.  The problem 
> is then reduced to overwriting "core.metadata" when you lose the lock.  One 
> way to fix this is to version "core.metadata".  Since the new leader election 
> code was implemented, each shard as a monotonically increasing "leader term", 
> and we can use that as part of the filename.  When a reader goes to open an 
> index, it can use the latest file from the directory listing, or even use the 
> term obtained from ZK if we can't trust the directory listing to be up to 
> date.  Additionally, we don't need random filenames to avoid collisions... a 
> simple unique prefix or suffix would work fine (such as the leader term again)



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

-
To unsubscribe, e-mail: 

[jira] [Commented] (SOLR-13050) SystemLogListener can "lose" record of nodeLost event when node lost is/was .system collection leader

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13050:


Commit e5fda5d6f1cc6010e6b3565aa4bd70be31621692 in lucene-solr's branch 
refs/heads/master from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e5fda5d ]

SOLR-13050: Fix the test so that .system events are collected again.


> SystemLogListener can "lose" record of nodeLost event when node lost is/was 
> .system collection leader
> -
>
> Key: SOLR-13050
> URL: https://issues.apache.org/jira/browse/SOLR-13050
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13050.test-workaround.patch, 
> jenkins.sarowe__Lucene-Solr-tests-7.x__7104.log.txt
>
>
> A chicken/egg issue of the way the autoscaling SystemLogListener uses the 
> {{.system}} collection to record event history is that in the case of a 
> {{nodeLost}} event for the {{.system}} collection's leader, there is a window 
> of time during leader election where trying to add the "Document" 
> representing that {{nodeLost}} event to the {{.system}} collection can fail.
> This isn't a silently failure: the SystemLogListener, acting the role of a 
> Solr client, is informed that the "add" failed, but it doesn't/can't do much 
> to deal with this situation other then to "log" (to the slf4j Logger) that it 
> wasn't able to add the doc.
> 
> I'm not sure how much of a "real world" impact this has on users, but I 
> noticed the issue while diagnosing a jenkins test failure and wanted to track 
> it.



--
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-13103) UnifiedHighlighter Separator-based BreakIterator should work with Strings, not just a single character

[Grant Ingersoll (JIRA)]

Grant Ingersoll created SOLR-13103:
--

 Summary: UnifiedHighlighter Separator-based BreakIterator should 
work with Strings, not just a single character
 Key: SOLR-13103
 URL: https://issues.apache.org/jira/browse/SOLR-13103
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: highlighter
Reporter: Grant Ingersoll


For the `hl.bs.type` choice of SEPARATOR, it would be nice if we could support 
not just a single character, but a string.  In looking at the code, I see no 
reason Strings can't be supported other than a few signature changes on some 
constructors.

 

My use case: I have docs that I have section and page markers that make for 
conveniently-sized passages for highlighting, but there really isn't any clean 
way to mark those sections with a single character.  For instance, Tika will 
extract and mark pages with ``.  If I could 
pass in that `` tag as my separator, I could then just 
highlight within a page.



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_172) - Build # 23450 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23450/
Java: 64bit/jdk1.8.0_172 -XX:+UseCompressedOops -XX:+UseSerialGC

7 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testAddNode

Error Message:
no STARTED event

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


FAILED:  org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testAddNode

Error Message:
no STARTED event

Stack Trace:
java.lang.AssertionError: no STARTED event
at 
__randomizedtesting.SeedInfo.seed([2D8DA5A0E4653244:8A62B8032B28BD5C]:0)
at 

[jira] [Created] (SOLR-13102) Shared storage Directory implementation

[Yonik Seeley (JIRA)]

Yonik Seeley created SOLR-13102:
---

 Summary: Shared storage Directory implementation
 Key: SOLR-13102
 URL: https://issues.apache.org/jira/browse/SOLR-13102
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Yonik Seeley


We need a general strategy (and probably a general base class) that can work 
with shared storage and not corrupt indexes from multiple writers.

One strategy that is used on local disk is to use locks.  This doesn't extend 
well to remote / shared filesystems when the locking is not tied into the 
object store itself since a process can lose the lock (a long GC or whatever) 
and then immediately try to write a file and there is no way to stop it.

An alternate strategy ditches the use of locks and simply avoids overwriting 
files by some algorithmic mechanism.
One of my colleagues outlined one way to do this: 
https://www.youtube.com/watch?v=UeTFpNeJ1Fo
That strategy uses random looking filenames and then writes a "core.metadata" 
file that maps between the random names and the original names.  The problem is 
then reduced to overwriting "core.metadata" when you lose the lock.  One way to 
fix this is to version "core.metadata".  Since the new leader election code was 
implemented, each shard as a monotonically increasing "leader term", and we can 
use that as part of the filename.  When a reader goes to open an index, it can 
use the latest file from the directory listing, or even use the term obtained 
from ZK if we can't trust the directory listing to be up to date.





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

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 5000 - Unstable!

[Policeman Jenkins Server]

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

8 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testAddNode

Error Message:
no STARTED event

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


FAILED:  org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testAddNode

Error Message:
no STARTED event

Stack Trace:
java.lang.AssertionError: no STARTED event
at 
__randomizedtesting.SeedInfo.seed([B61ABF3E71772D4D:11F5A29DBE3AA255]:0)
at org.junit.Assert.fail(Assert.java:88)

[jira] [Created] (SOLR-13101) Shared storage support in SolrCloud

[Yonik Seeley (JIRA)]

Yonik Seeley created SOLR-13101:
---

 Summary: Shared storage support in SolrCloud
 Key: SOLR-13101
 URL: https://issues.apache.org/jira/browse/SOLR-13101
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Reporter: Yonik Seeley


Solr should have first-class support for shared storage (blob/object stores 
like S3, google cloud storage, etc. and shared filesystems like HDFS, NFS, etc).

The key component will likely be a new replica type for shared storage.  It 
would have many of the benefits of the current "pull" replicas (not indexing on 
all replicas, all shards identical with no shards getting out-of-sync, etc), 
but would have additional benefits:
 - Any shard could become leader (the blob store always has the index)
 - Better elasticity scaling down
   - durability not linked to number of replcias.. a single replica could be 
common for write workloads
   - could drop to 0 replicas for a shard when not needed (blob store always 
has index)
 - Allow for higher performance write workloads by skipping the transaction log
   - don't pay for what you don't need
   - a commit will be necessary to flush to stable storage (blob store)
 - A lot of the complexity and failure modes go away

An additional component a Directory implementation that will work well with 
blob stores.  We probably want one that treats local disk as a cache since the 
latency to remote storage is so large.  I think there are still some "locking" 
issues to be solved here (ensuring that more than one writer to the same index 
won't corrupt it).  This should probably be pulled out into a different JIRA 
issue.




--
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-13100) harden/manage connectionpool used for intra-cluster communication when we know nodes go down

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-13100:


I can spend a little more time here, but a quick reply.

 

HTTP 1/1.1 has a race condition around stale connections that cannot be 
overcome - though it can be defended against, and we have put a lot of effort 
there. Restarting a test Jetty instance is still a problem area - I think you 
can work around it by making explicit calls to the pool to check for expired 
connections at the right time, but otherwise it's done on a timer with a thread 
and somehow shutting down Jetty and starting it again does not play quite 
correctly with our stale connection avoidance strategy (try to make client 
manage the connection lifecycle instead of the server). We used to have more 
control over some of theinner workings around sweeping for idle connections and 
such, but now I think we use more internal impls with a newer http client 
version. I think the speed of an integration test makes this an issue, I think 
it's less likely to see real world.

HTTP 2 has no such problems with this race, you can just see if a connection is 
valid, so I think this just goes away with 8.

> harden/manage connectionpool used for intra-cluster communication when we 
> know nodes go down
> 
>
> Key: SOLR-13100
> URL: https://issues.apache.org/jira/browse/SOLR-13100
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Major
>
> I'm spinng this idea off of some comments i made in SOLR-13028...
> In that issue, in discussion of some test failures that can happen after a 
> node is shutdown/restarted (new emphasis added)...
> {quote}
> The bit where the test fails is that it:
> # shuts down a jetty instance
> # starts the jetty instance again
> # does some waiting for all the collections to be "active" and all the 
> replicas to be "live"
> # tries to send an auto-scalling 'set-cluster-preferences' config change to 
> the cluster
> The bit of test code where it does this creates an entirely new 
> CLoudSolrClient, ignoring the existing one except for the ZKServer address, 
> w/an explicit comment that the reason it's doing this is because the 
> connection pool on the existing CloudSolrClient might have a stale connection 
> to the old (Ie: dead) instance of the restarted jetty...
>   ...
> ...doing this ensures that the cloudClient doesn't try to query the "dead" 
> server directly (on a stale connection) but IIUC this issue of stale 
> connections to the dead server instance is still problematic - and the root 
> cause of this failure - because after the CloudSolrClient picks a random node 
> to send the request to, _on the remote solr side, that node then has to 
> dispatch a request to each and every node, and at that point the node doing 
> the distributed dispatch may also have a stale connection pool pointing at a 
> server instance that's no longer listening._
> {quote}
> *The point of this issue is to explore, if/how we can -- in general -- better 
> deal with pooled connections in situations where the cluster state knows that 
> an existing node has gone down, or been restarted.*
> SOLR-13028 is a particular example of when/how stale pooled conection info 
> can cause test problems -- and the bulk of the discussion in that issue is 
> about how that specific code path (in dealing with an intra-cl autoscaling 
> handler command dispatch) can be improved to do a retry in the event of 
> NoHttpResponseException -- but not ever place where solr nodes need to talk 
> to each other can blindly retry on every possible connection exception; and 
> even when we can, it would be better if we could minimize the risk of the 
> request failing in a way that would require a retry.
> *So why not improve our HTTP connection pool to be aware of our clusterstate 
> and purge connections when we know odes have been shutdown/lost?*



--
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-13097) RuleBasedAuthorizationPlugin is not fully fonctionnal in Solr standalone mode

[JIRA]

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

Dominique Béjean updated SOLR-13097:

Environment: Solr standalone

> RuleBasedAuthorizationPlugin is not fully fonctionnal in Solr standalone mode
> -
>
> Key: SOLR-13097
> URL: https://issues.apache.org/jira/browse/SOLR-13097
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: 6.6.5, 7.5
> Environment: Solr standalone
>Reporter: Dominique Béjean
>Priority: Major
>
> In Solr standalone mode, the collections element of the request context is 
> not populated by the core name.
> For instance, the following request:
> {code:java}
> http://user1:xx@localhost:8983/solr/biblio/select?indent=on=*:*=json{code}
> reports this in log:
> {code:java}
> 2018-12-30 12:24:52.102 INFO (qtp1731656333-20) [ x:biblio] 
> o.a.s.s.HttpSolrCall USER_REQUIRED auth header Basic Mjox context : 
> userPrincipal: [[principal: 2]] type: [READ], collections: [], Path: 
> [/select] path : /select params :q=:=on=json{code}
> The consequence is that RuleBasedAuthorizationPlugin is not able to apply 
> this kind of permission:
> {code:java}
> {"name":"read-biblio",
>  "path":"/select",
>  "role":["admin","read","r1"],
>  "collection":"biblio",
>  "index":2}{code}
> In Solrcloud mode in the init() method of HttpSolrCall.java, the collections 
> element is populated with either the collection name matching the core name 
> in the request or the collection names provided in the collection parameter.
> {code:java}
> if (cores.isZooKeeperAware()) {
>      // init collectionList (usually one name but not when there are aliases)
>      String def = core != null ? core.getCoreDescriptor().getCollectionName() 
> : origCorename;
>      collectionsList = 
> resolveCollectionListOrAlias(queryParams.get(COLLECTION_PROP, def)); // 
> = takes precedence
> ...
> }{code}
>  
> I expect init() method could be improved in order to populate collections 
> element with the core name for Solr standalone mode.
>  



--
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-7.x-Linux (64bit/jdk-11) - Build # 3329 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/3329/
Java: 64bit/jdk-11 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestCloudSearcherWarming

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestCloudSearcherWarming: 1) Thread[id=26771, 
name=SessionTracker, state=TIMED_WAITING, group=TGRP-TestCloudSearcherWarming]  
   at java.base@11/java.lang.Object.wait(Native Method) at 
app//org.apache.zookeeper.server.SessionTrackerImpl.run(SessionTrackerImpl.java:147)
2) Thread[id=26773, name=ProcessThread(sid:0 cport:41841):, state=WAITING, 
group=TGRP-TestCloudSearcherWarming] at 
java.base@11/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)  
   at 
java.base@11/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@11/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
app//org.apache.zookeeper.server.PrepRequestProcessor.run(PrepRequestProcessor.java:123)
3) Thread[id=26769, name=ZkTestServer Run Thread, state=WAITING, 
group=TGRP-TestCloudSearcherWarming] at 
java.base@11/java.lang.Object.wait(Native Method) at 
java.base@11/java.lang.Thread.join(Thread.java:1305) at 
java.base@11/java.lang.Thread.join(Thread.java:1379) at 
app//org.apache.zookeeper.server.NIOServerCnxnFactory.join(NIOServerCnxnFactory.java:313)
 at 
app//org.apache.solr.cloud.ZkTestServer$ZKServerMain.runFromConfig(ZkTestServer.java:343)
 at 
app//org.apache.solr.cloud.ZkTestServer$2.run(ZkTestServer.java:564)4) 
Thread[id=26772, name=SyncThread:0, state=WAITING, 
group=TGRP-TestCloudSearcherWarming] at 
java.base@11/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)  
   at 
java.base@11/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@11/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
app//org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:127)
5) Thread[id=26770, name=NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0, 
state=RUNNABLE, group=TGRP-TestCloudSearcherWarming] at 
java.base@11/sun.nio.ch.EPoll.wait(Native Method) at 
java.base@11/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)  
   at 
java.base@11/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) 
at java.base@11/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136)   
  at 
app//org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:196)
 at java.base@11/java.lang.Thread.run(Thread.java:834)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestCloudSearcherWarming: 
   1) Thread[id=26771, name=SessionTracker, state=TIMED_WAITING, 
group=TGRP-TestCloudSearcherWarming]
at java.base@11/java.lang.Object.wait(Native Method)
at 
app//org.apache.zookeeper.server.SessionTrackerImpl.run(SessionTrackerImpl.java:147)
   2) Thread[id=26773, name=ProcessThread(sid:0 cport:41841):, state=WAITING, 
group=TGRP-TestCloudSearcherWarming]
at java.base@11/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@11/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 
java.base@11/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
at 
java.base@11/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
at 
app//org.apache.zookeeper.server.PrepRequestProcessor.run(PrepRequestProcessor.java:123)
   3) Thread[id=26769, name=ZkTestServer Run Thread, state=WAITING, 
group=TGRP-TestCloudSearcherWarming]
at java.base@11/java.lang.Object.wait(Native Method)
at java.base@11/java.lang.Thread.join(Thread.java:1305)
at java.base@11/java.lang.Thread.join(Thread.java:1379)
at 
app//org.apache.zookeeper.server.NIOServerCnxnFactory.join(NIOServerCnxnFactory.java:313)
at 
app//org.apache.solr.cloud.ZkTestServer$ZKServerMain.runFromConfig(ZkTestServer.java:343)
at app//org.apache.solr.cloud.ZkTestServer$2.run(ZkTestServer.java:564)
   4) Thread[id=26772, name=SyncThread:0, state=WAITING, 
group=TGRP-TestCloudSearcherWarming]
at java.base@11/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@11/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 

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

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/2605/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/420/consoleText

[repro] Revision: 2ccb505912f5ee1818112e27518154b606b7512e

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=TestIndexingSequenceNumbers 
-Dtests.method=testStressConcurrentCommit -Dtests.seed=355CECFE06839C71 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=sv-SE -Dtests.timezone=America/Indiana/Petersburg 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=Test2BPostings -Dtests.method=test 
-Dtests.seed=355CECFE06839C71 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=und -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestIntRangeFieldQueries 
-Dtests.method=testRandomBig -Dtests.seed=355CECFE06839C71 -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=da-DK -Dtests.timezone=Africa/Libreville -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=CdcrReplicationHandlerTest 
-Dtests.method=testReplicationWithBufferedUpdates -Dtests.seed=149E22421D519306 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=fr-BE -Dtests.timezone=Europe/Tiraspol -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestSimTriggerIntegration 
-Dtests.method=testNodeLostTriggerRestoreState -Dtests.seed=149E22421D519306 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=es-AR -Dtests.timezone=Indian/Chagos -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestSimLargeCluster 
-Dtests.seed=149E22421D519306 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=es-PE -Dtests.timezone=America/Detroit -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: 
a1c6e642aad90d3615b4c71bf261a5aad7e32369
[repro] git fetch
[repro] git checkout 2ccb505912f5ee1818112e27518154b606b7512e

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

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

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   TestSimTriggerIntegration
[repro]   TestSimLargeCluster
[repro]   CdcrReplicationHandlerTest
[repro]lucene/core
[repro]   TestIntRangeFieldQueries
[repro]   Test2BPostings
[repro]   TestIndexingSequenceNumbers
[repro] ant compile-test

[...truncated 3605 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.TestSimTriggerIntegration|*.TestSimLargeCluster|*.CdcrReplicationHandlerTest"
 -Dtests.showOutput=onerror -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=149E22421D519306 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=es-AR -Dtests.timezone=Indian/Chagos -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

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

[repro] ant compile-test

[...truncated 112 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.TestIntRangeFieldQueries|*.Test2BPostings|*.TestIndexingSequenceNumbers"
 -Dtests.showOutput=onerror -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=355CECFE06839C71 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 

[jira] [Commented] (SOLR-13100) harden/manage connectionpool used for intra-cluster communication when we know nodes go down

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-13100:
-

In addition to SOLR-13028, SOLR-13038 is another example where a test failure 
demonstrates a "real world" problem with these stale connections being used.

There is also some older context/discussion in SOLR-6944 - although it's mostly 
about the retry logic, and less specific discussion about the connection pool 
management.

[~markrmil...@gmail.com] - as the person whose spent the most time looking at 
this in the past, it would be really helpful if you could cohesively & 
comprehensively summarize your past experiments/experiences in this area -- 
lots of issues seem to have danced around this idea in the past w/o any 
definitive discussion ... it would be great if we had some clear cut guidence 
like "X won't work because of Y" or "Z might work but I haven't tried it 
because of Q" or "V seemed promising but at theime we had to worry about W and 
i don't know if that'sstill an isue because of U"

> harden/manage connectionpool used for intra-cluster communication when we 
> know nodes go down
> 
>
> Key: SOLR-13100
> URL: https://issues.apache.org/jira/browse/SOLR-13100
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Major
>
> I'm spinng this idea off of some comments i made in SOLR-13028...
> In that issue, in discussion of some test failures that can happen after a 
> node is shutdown/restarted (new emphasis added)...
> {quote}
> The bit where the test fails is that it:
> # shuts down a jetty instance
> # starts the jetty instance again
> # does some waiting for all the collections to be "active" and all the 
> replicas to be "live"
> # tries to send an auto-scalling 'set-cluster-preferences' config change to 
> the cluster
> The bit of test code where it does this creates an entirely new 
> CLoudSolrClient, ignoring the existing one except for the ZKServer address, 
> w/an explicit comment that the reason it's doing this is because the 
> connection pool on the existing CloudSolrClient might have a stale connection 
> to the old (Ie: dead) instance of the restarted jetty...
>   ...
> ...doing this ensures that the cloudClient doesn't try to query the "dead" 
> server directly (on a stale connection) but IIUC this issue of stale 
> connections to the dead server instance is still problematic - and the root 
> cause of this failure - because after the CloudSolrClient picks a random node 
> to send the request to, _on the remote solr side, that node then has to 
> dispatch a request to each and every node, and at that point the node doing 
> the distributed dispatch may also have a stale connection pool pointing at a 
> server instance that's no longer listening._
> {quote}
> *The point of this issue is to explore, if/how we can -- in general -- better 
> deal with pooled connections in situations where the cluster state knows that 
> an existing node has gone down, or been restarted.*
> SOLR-13028 is a particular example of when/how stale pooled conection info 
> can cause test problems -- and the bulk of the discussion in that issue is 
> about how that specific code path (in dealing with an intra-cl autoscaling 
> handler command dispatch) can be improved to do a retry in the event of 
> NoHttpResponseException -- but not ever place where solr nodes need to talk 
> to each other can blindly retry on every possible connection exception; and 
> even when we can, it would be better if we could minimize the risk of the 
> request failing in a way that would require a retry.
> *So why not improve our HTTP connection pool to be aware of our clusterstate 
> and purge connections when we know odes have been shutdown/lost?*



--
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-8621) Move LatLonShape out of sandbox

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-8621:
--

BTW I already filed an issue to remove the spatial module and worked on it 
including a patch but [~jpountz] wasn't sure about that since it seemed 
LatLonShape would wind up there: 
https://issues.apache.org/jira/browse/LUCENE-8369?focusedCommentId=16525475=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16525475

While I'm a fan of having either no spatial or simple spatial in lucene-core, 
I'm also in favor of simplifying the user experience by reducing the number of 
places they will find spatial stuff.  Balancing the two, and given the slippery 
slope of spatial already in lucene-core, I think it's best to remove the 
spatial module and put LatLonShape into core.

> Move LatLonShape out of sandbox
> ---
>
> Key: LUCENE-8621
> URL: https://issues.apache.org/jira/browse/LUCENE-8621
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> LatLonShape has matured a lot over the last months, I'd like to start 
> thinking about moving it out of sandbox so that it doesn't stay there for too 
> long like what happened to LatLonPoint. I am pretty happy with the current 
> encoding. To my knowledge, we might just need to do a minor modification 
> because of 
> LUCENE-8620.



--
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: Congratulations to the new Lucene/Solr PMC chair, Cassandra Targett

[Kevin Risden]

Congrats!

Kevin Risden

On Wed, Jan 2, 2019 at 1:36 PM Anshum Gupta  wrote:
>
> Congratulations, Cassandra!
>
> On Sun, Dec 30, 2018 at 11:38 PM Adrien Grand  wrote:
>>
>> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache
>> Vice President position.
>>
>> This year we have nominated and elected Cassandra Targett as the
>> chair, a decision that the board approved in its December 2018
>> meeting.
>>
>> Congratulations, Cassandra!
>>
>> --
>> Adrien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> --
> Anshum Gupta

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

[jira] [Created] (SOLR-13100) harden/manage connectionpool used for intra-cluster communication when we know nodes go down

[Hoss Man (JIRA)]

Hoss Man created SOLR-13100:
---

 Summary: harden/manage connectionpool used for intra-cluster 
communication when we know nodes go down
 Key: SOLR-13100
 URL: https://issues.apache.org/jira/browse/SOLR-13100
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


I'm spinng this idea off of some comments i made in SOLR-13028...

In that issue, in discussion of some test failures that can happen after a node 
is shutdown/restarted (new emphasis added)...

{quote}
The bit where the test fails is that it:

# shuts down a jetty instance
# starts the jetty instance again
# does some waiting for all the collections to be "active" and all the replicas 
to be "live"
# tries to send an auto-scalling 'set-cluster-preferences' config change to the 
cluster

The bit of test code where it does this creates an entirely new 
CLoudSolrClient, ignoring the existing one except for the ZKServer address, 
w/an explicit comment that the reason it's doing this is because the connection 
pool on the existing CloudSolrClient might have a stale connection to the old 
(Ie: dead) instance of the restarted jetty...
  ...
...doing this ensures that the cloudClient doesn't try to query the "dead" 
server directly (on a stale connection) but IIUC this issue of stale 
connections to the dead server instance is still problematic - and the root 
cause of this failure - because after the CloudSolrClient picks a random node 
to send the request to, _on the remote solr side, that node then has to 
dispatch a request to each and every node, and at that point the node doing the 
distributed dispatch may also have a stale connection pool pointing at a server 
instance that's no longer listening._
{quote}

*The point of this issue is to explore, if/how we can -- in general -- better 
deal with pooled connections in situations where the cluster state knows that 
an existing node has gone down, or been restarted.*

SOLR-13028 is a particular example of when/how stale pooled conection info can 
cause test problems -- and the bulk of the discussion in that issue is about 
how that specific code path (in dealing with an intra-cl autoscaling handler 
command dispatch) can be improved to do a retry in the event of 
NoHttpResponseException -- but not ever place where solr nodes need to talk to 
each other can blindly retry on every possible connection exception; and even 
when we can, it would be better if we could minimize the risk of the request 
failing in a way that would require a retry.

*So why not improve our HTTP connection pool to be aware of our clusterstate 
and purge connections when we know odes have been shutdown/lost?*



--
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-8527) Upgrade JFlex to 1.7.0

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-8527:


bq. \[W\]ith the default skeleton, JFlex 1.7.0 generates scanners that 
misbehaves when given a spoon-feeding reader (i.e. a reader that returns at 
least one char but fewer than the requested number of chars) \[\] I'll make 
a JFlex issue for this bug.

I created an issue: https://github.com/jflex-de/jflex/issues/538

bq. \[I\]nvocations of JFlex's Ant target inherit options used by previous 
invocations in the same Ant session. I'll make a JFlex issue for this bug.

There has been an ongoing effort to fix this, see: 
https://github.com/jflex-de/jflex/pull/258 , likely will be included in next 
JFlex release.


> Upgrade JFlex to 1.7.0
> --
>
> Key: LUCENE-8527
> URL: https://issues.apache.org/jira/browse/LUCENE-8527
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build, modules/analysis
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: LUCENE-8527.patch, LUCENE-8527.patch
>
>
> JFlex 1.7.0, supporting Unicode 9.0, was released recently: 
> [http://jflex.de/changelog.html#jflex-1.7.0].  We should upgrade.



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

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

[JENKINS] Lucene-Solr-BadApples-Tests-7.x - Build # 255 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/255/

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

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

Stack Trace:
java.lang.AssertionError: Doc with id=4 not found in 
https://127.0.0.1:36884/solr/outOfSyncReplicasCannotBecomeLeader-false due to: 
Path not found: /id; rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([661C9259E9C10839:18F7B2492AA60703]: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 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)
  

Re: Congratulations to the new Lucene/Solr PMC chair, Cassandra Targett

[Anshum Gupta]

Congratulations, Cassandra!

On Sun, Dec 30, 2018 at 11:38 PM Adrien Grand  wrote:

> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache
> Vice President position.
>
> This year we have nominated and elected Cassandra Targett as the
> chair, a decision that the board approved in its December 2018
> meeting.
>
> Congratulations, Cassandra!
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Anshum Gupta

[jira] [Comment Edited] (LUCENE-8621) Move LatLonShape out of sandbox

[Nicholas Knize (JIRA)]

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

Nicholas Knize edited comment on LUCENE-8621 at 1/2/19 6:33 PM:


+1

I can take this one. I vote:
 # Move {{LatLonShape}} to {{core}} as a companion to {{LatLonPoint}}
 # In a separate issue, refactor (or remove where appropriate) the two 
remaining classes ( {{GeoRelationUtils}} && {{MortonEncoder}} ) from the 
{{spatial}} module to either the {{core}} or {{spatial-extras module}}
 # Remove the {{spatial}} module 

 We can do the refactor for 8.0 and keep it in sandbox for 7.7 leaving the 7.x 
line consistent?

 


was (Author: nknize):
+1

I can take this one. I vote:
 # Move {{LatLonShape}} to {{core}} as a companion to {{LatLonPoint}}
 # In a separate issue, refactor (or remove where appropriate) the two 
remaining classes ({{GeoRelationUtils && {{MortonEncoder) from the 
{{spatial}} module to either the {{core}} or {{spatial-extras module}}
 # Remove the {{spatial}} module 

 We can do the refactor for 8.0 and keep it in sandbox for 7.7 leaving the 7.x 
line consistent?

 

> Move LatLonShape out of sandbox
> ---
>
> Key: LUCENE-8621
> URL: https://issues.apache.org/jira/browse/LUCENE-8621
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> LatLonShape has matured a lot over the last months, I'd like to start 
> thinking about moving it out of sandbox so that it doesn't stay there for too 
> long like what happened to LatLonPoint. I am pretty happy with the current 
> encoding. To my knowledge, we might just need to do a minor modification 
> because of 
> LUCENE-8620.



--
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-8621) Move LatLonShape out of sandbox

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-8621:


+1

I can take this one. I vote:
 # Move {{LatLonShape}} to {{core}} as a companion to {{LatLonPoint}}
 # In a separate issue, refactor (or remove where appropriate) the two 
remaining classes ({{GeoRelationUtils && {{MortonEncoder) from the 
{{spatial}} module to either the {{core}} or {{spatial-extras module}}
 # Remove the {{spatial}} module 

 We can do the refactor for 8.0 and keep it in sandbox for 7.7 leaving the 7.x 
line consistent?

 

> Move LatLonShape out of sandbox
> ---
>
> Key: LUCENE-8621
> URL: https://issues.apache.org/jira/browse/LUCENE-8621
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> LatLonShape has matured a lot over the last months, I'd like to start 
> thinking about moving it out of sandbox so that it doesn't stay there for too 
> long like what happened to LatLonPoint. I am pretty happy with the current 
> encoding. To my knowledge, we might just need to do a minor modification 
> because of 
> LUCENE-8620.



--
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-8627) TestSearchAfter.testQueries() failure

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8627:
--

[~erickerickson] This test bug only affects master, 7.x should be fine.

> TestSearchAfter.testQueries() failure
> -
>
> Key: LUCENE-8627
> URL: https://issues.apache.org/jira/browse/LUCENE-8627
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>Priority: Major
> Fix For: master (8.0)
>
>
> From [https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1735], 
> reproduces 10/10 iterations for me:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSearchAfter 
> -Dtests.method=testQueries -Dtests.seed=C0154BFB98528228 -Dtests.multiplier=2 
> -Dtests.nightly=true -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
>  -Dtests.locale=sr-ME -Dtests.timezone=Africa/Timbuktu -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.34s J2 | TestSearchAfter.testQueries <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1082> but 
> was:<1000>
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([C0154BFB98528228:9C9B8720823B3786]:0)
>[junit4]>at 
> org.apache.lucene.search.TestSearchAfter.assertPage(TestSearchAfter.java:268)
>[junit4]>at 
> org.apache.lucene.search.TestSearchAfter.assertQuery(TestSearchAfter.java:260)
>[junit4]>at 
> org.apache.lucene.search.TestSearchAfter.testQueries(TestSearchAfter.java:183)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=CheapBastard, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@6f9a6df3),
>  locale=sr-ME, timezone=Africa/Timbuktu
>[junit4]   2> NOTE: Linux 4.4.0-137-generic amd64/Oracle Corporation 
> 1.8.0_191 (64-bit)/cpus=4,threads=1,free=174481080,total=519045120
> {noformat}



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

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_172) - Build # 23449 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23449/
Java: 32bit/jdk1.8.0_172 -server -XX:+UseG1GC

11 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testAddNode

Error Message:
no STARTED event

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


FAILED:  org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testAddNode

Error Message:
no STARTED event

Stack Trace:
java.lang.AssertionError: no STARTED event
at 
__randomizedtesting.SeedInfo.seed([734C4DC58858AE19:D4A3506647152101]:0)
at org.junit.Assert.fail(Assert.java:88)
at 

Re: Congratulations to the new Lucene/Solr PMC chair, Cassandra Targett

[Trey Grainger]

Congratulations, Cassandra!

On Wed, Jan 2, 2019 at 9:31 AM Joel Bernstein  wrote:

> Congratulations Cassandra!
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
>
> On Wed, Jan 2, 2019 at 8:39 AM Tommaso Teofili 
> wrote:
>
>> Congrats Cassandra!
>> Il giorno mer 2 gen 2019 alle ore 12:43 Shalin Shekhar Mangar
>>  ha scritto:
>> >
>> > Congratulations Cassandra!
>> >
>> > On Mon, Dec 31, 2018 at 1:08 PM Adrien Grand  wrote:
>> >>
>> >> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache
>> >> Vice President position.
>> >>
>> >> This year we have nominated and elected Cassandra Targett as the
>> >> chair, a decision that the board approved in its December 2018
>> >> meeting.
>> >>
>> >> Congratulations, Cassandra!
>> >>
>> >> --
>> >> Adrien
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>
>> >
>> >
>> > --
>> > Regards,
>> > Shalin Shekhar Mangar.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

[jira] [Commented] (LUCENE-8627) TestSearchAfter.testQueries() failure

[Erick Erickson (JIRA)]

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

Erick Erickson commented on LUCENE-8627:


Any chance to backport to 7x? It's still up in the air whether we'll release a 
Solr 7.7 coincident with 8.0 just to put a bow on the 7x code line

Since it's a test it's less of a concern of course

> TestSearchAfter.testQueries() failure
> -
>
> Key: LUCENE-8627
> URL: https://issues.apache.org/jira/browse/LUCENE-8627
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>Priority: Major
> Fix For: master (8.0)
>
>
> From [https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1735], 
> reproduces 10/10 iterations for me:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSearchAfter 
> -Dtests.method=testQueries -Dtests.seed=C0154BFB98528228 -Dtests.multiplier=2 
> -Dtests.nightly=true -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
>  -Dtests.locale=sr-ME -Dtests.timezone=Africa/Timbuktu -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.34s J2 | TestSearchAfter.testQueries <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1082> but 
> was:<1000>
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([C0154BFB98528228:9C9B8720823B3786]:0)
>[junit4]>at 
> org.apache.lucene.search.TestSearchAfter.assertPage(TestSearchAfter.java:268)
>[junit4]>at 
> org.apache.lucene.search.TestSearchAfter.assertQuery(TestSearchAfter.java:260)
>[junit4]>at 
> org.apache.lucene.search.TestSearchAfter.testQueries(TestSearchAfter.java:183)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=CheapBastard, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@6f9a6df3),
>  locale=sr-ME, timezone=Africa/Timbuktu
>[junit4]   2> NOTE: Linux 4.4.0-137-generic amd64/Oracle Corporation 
> 1.8.0_191 (64-bit)/cpus=4,threads=1,free=174481080,total=519045120
> {noformat}



--
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 pull request #305: SOLR-11853: Make check for used tool "service...

[Mandalka]

Github user Mandalka closed the pull request at:

https://github.com/apache/lucene-solr/pull/305


---

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

[GitHub] lucene-solr issue #305: SOLR-11853: Make check for used tool "service" compa...

[Mandalka]

Github user Mandalka commented on the issue:

https://github.com/apache/lucene-solr/pull/305
  
This PR was solved by 
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a1c6e64 so rest 
like missing group solr and rights of /etc/default/$SOLR_SERVICE.in.sh and 
setting Solr users shell from /bin/false to bash can be set after installation 
without patching original Solr files.


---

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

[jira] [Commented] (SOLR-11853) Solr installer fails on SuSE linux (Make check for used tool "service" compatible with SuSE Linux like OpenSuse or SLES)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11853:


Commit f2f0110b9ac92a0cd43a6c3ebccbb7abe83177a7 in lucene-solr's branch 
refs/heads/branch_7x from Jan Høydahl
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f2f0110 ]

SOLR-11853: Solr installer fails on SuSE linux

(cherry picked from commit a1c6e642aad90d3615b4c71bf261a5aad7e32369)


> Solr installer fails on SuSE linux (Make check for used tool "service" 
> compatible with SuSE Linux like OpenSuse or SLES)
> 
>
> Key: SOLR-11853
> URL: https://issues.apache.org/jira/browse/SOLR-11853
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.0.1, 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5
> Environment: SuSE Linux (SLES & OpenSuSE)
>Reporter: Markus Mandalka
>Assignee: Jan Høydahl
>Priority: Minor
>  Labels: github-import, newbie, patch
> Fix For: master (8.0), 7.7
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> On current SuSE Linux releases like SLES or OpenSuSE the Solr installer stops 
> with the error message "Script requires the 'service' command".
> This happens because before installation the installer checks if the used 
> command "service" exists by its option "service --version".
> The command line option "--version" doesn't exist for "service" on current 
> SuSE Linux stable releases.
> Since the command "service" is there and has an option "--help", this option 
> can be used as additional fallback.
> So in the pull request i extended the check with "service --help" as second 
> check / fallback before printing this error and exiting.



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

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

[jira] [Resolved] (SOLR-13090) Make maxBooleanClauses support system-property override

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski resolved SOLR-13090.

   Resolution: Fixed
Fix Version/s: 7.7
   master (8.0)

> Make maxBooleanClauses support system-property override
> ---
>
> Key: SOLR-13090
> URL: https://issues.apache.org/jira/browse/SOLR-13090
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (8.0), 7.7
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Fix For: master (8.0), 7.7
>
> Attachments: SOLR-13090.patch
>
>
> Currently, the {{maxBooleanClauses}} property is specified in most 
> solrconfig's as the hardcoded value "1024".  It'd be nice if we changed our 
> shipped configs so that they instead specified it as 
> {{${solr.max.booleanClauses:1024} This would maintain the current OOTB behavior (maxBooleanClauses would still 
> default to 1024) while adding the ability to update maxBooleanClauses values 
> across the board much more easily.  (I see users want to do this often when 
> they first run up against this limit.)



--
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-13090) Make maxBooleanClauses support system-property override

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13090:


Commit fd4df572e94aa1504efcd08a6538bbda428214d2 in lucene-solr's branch 
refs/heads/branch_7x from Jason Gerlowski
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fd4df57 ]

SOLR-13090: Add sysprop override for maxBooleanClauses


> Make maxBooleanClauses support system-property override
> ---
>
> Key: SOLR-13090
> URL: https://issues.apache.org/jira/browse/SOLR-13090
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (8.0), 7.7
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13090.patch
>
>
> Currently, the {{maxBooleanClauses}} property is specified in most 
> solrconfig's as the hardcoded value "1024".  It'd be nice if we changed our 
> shipped configs so that they instead specified it as 
> {{${solr.max.booleanClauses:1024} This would maintain the current OOTB behavior (maxBooleanClauses would still 
> default to 1024) while adding the ability to update maxBooleanClauses values 
> across the board much more easily.  (I see users want to do this often when 
> they first run up against this limit.)



--
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-13050) SystemLogListener can "lose" record of nodeLost event when node lost is/was .system collection leader

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13050:


Commit 0f0b80ff63f6d1f4e746c6463f442a48f26100f3 in lucene-solr's branch 
refs/heads/branch_7x from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0f0b80f ]

SOLR-13050: Fix another test that could accidentally kill the .system leader 
node.
Improve fallback in SystemLogListener when target collection is not present.


> SystemLogListener can "lose" record of nodeLost event when node lost is/was 
> .system collection leader
> -
>
> Key: SOLR-13050
> URL: https://issues.apache.org/jira/browse/SOLR-13050
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13050.test-workaround.patch, 
> jenkins.sarowe__Lucene-Solr-tests-7.x__7104.log.txt
>
>
> A chicken/egg issue of the way the autoscaling SystemLogListener uses the 
> {{.system}} collection to record event history is that in the case of a 
> {{nodeLost}} event for the {{.system}} collection's leader, there is a window 
> of time during leader election where trying to add the "Document" 
> representing that {{nodeLost}} event to the {{.system}} collection can fail.
> This isn't a silently failure: the SystemLogListener, acting the role of a 
> Solr client, is informed that the "add" failed, but it doesn't/can't do much 
> to deal with this situation other then to "log" (to the slf4j Logger) that it 
> wasn't able to add the doc.
> 
> I'm not sure how much of a "real world" impact this has on users, but I 
> noticed the issue while diagnosing a jenkins test failure and wanted to track 
> it.



--
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-11853) Solr installer fails on SuSE linux (Make check for used tool "service" compatible with SuSE Linux like OpenSuse or SLES)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11853:


Commit a1c6e642aad90d3615b4c71bf261a5aad7e32369 in lucene-solr's branch 
refs/heads/master from Jan Høydahl
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a1c6e64 ]

SOLR-11853: Solr installer fails on SuSE linux


> Solr installer fails on SuSE linux (Make check for used tool "service" 
> compatible with SuSE Linux like OpenSuse or SLES)
> 
>
> Key: SOLR-11853
> URL: https://issues.apache.org/jira/browse/SOLR-11853
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.0.1, 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5
> Environment: SuSE Linux (SLES & OpenSuSE)
>Reporter: Markus Mandalka
>Assignee: Jan Høydahl
>Priority: Minor
>  Labels: github-import, newbie, patch
> Fix For: master (8.0), 7.7
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> On current SuSE Linux releases like SLES or OpenSuSE the Solr installer stops 
> with the error message "Script requires the 'service' command".
> This happens because before installation the installer checks if the used 
> command "service" exists by its option "service --version".
> The command line option "--version" doesn't exist for "service" on current 
> SuSE Linux stable releases.
> Since the command "service" is there and has an option "--help", this option 
> can be used as additional fallback.
> So in the pull request i extended the check with "service --help" as second 
> check / fallback before printing this error and exiting.



--
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-11853) Solr installer fails on SuSE linux (Make check for used tool "service" compatible with SuSE Linux like OpenSuse or SLES)

[JIRA]

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

Jan Høydahl reassigned SOLR-11853:
--

Assignee: Jan Høydahl

> Solr installer fails on SuSE linux (Make check for used tool "service" 
> compatible with SuSE Linux like OpenSuse or SLES)
> 
>
> Key: SOLR-11853
> URL: https://issues.apache.org/jira/browse/SOLR-11853
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.0.1, 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5
> Environment: SuSE Linux (SLES & OpenSuSE)
>Reporter: Markus Mandalka
>Assignee: Jan Høydahl
>Priority: Minor
>  Labels: github-import, newbie, patch
> Fix For: 7.6, master (8.0)
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> On current SuSE Linux releases like SLES or OpenSuSE the Solr installer stops 
> with the error message "Script requires the 'service' command".
> This happens because before installation the installer checks if the used 
> command "service" exists by its option "service --version".
> The command line option "--version" doesn't exist for "service" on current 
> SuSE Linux stable releases.
> Since the command "service" is there and has an option "--help", this option 
> can be used as additional fallback.
> So in the pull request i extended the check with "service --help" as second 
> check / fallback before printing this error and exiting.



--
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-11853) Solr installer fails on SuSE linux (Make check for used tool "service" compatible with SuSE Linux like OpenSuse or SLES)

[JIRA]

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

Jan Høydahl updated SOLR-11853:
---
Fix Version/s: (was: 7.6)
   7.7

> Solr installer fails on SuSE linux (Make check for used tool "service" 
> compatible with SuSE Linux like OpenSuse or SLES)
> 
>
> Key: SOLR-11853
> URL: https://issues.apache.org/jira/browse/SOLR-11853
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.0.1, 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5
> Environment: SuSE Linux (SLES & OpenSuSE)
>Reporter: Markus Mandalka
>Assignee: Jan Høydahl
>Priority: Minor
>  Labels: github-import, newbie, patch
> Fix For: master (8.0), 7.7
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> On current SuSE Linux releases like SLES or OpenSuSE the Solr installer stops 
> with the error message "Script requires the 'service' command".
> This happens because before installation the installer checks if the used 
> command "service" exists by its option "service --version".
> The command line option "--version" doesn't exist for "service" on current 
> SuSE Linux stable releases.
> Since the command "service" is there and has an option "--help", this option 
> can be used as additional fallback.
> So in the pull request i extended the check with "service --help" as second 
> check / fallback before printing this error and exiting.



--
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-7.x-Linux (64bit/jdk-9.0.4) - Build # 3328 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/3328/
Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats

Error Message:
Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1

Stack Trace:
java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
registry solr.core.collection1
at 
__randomizedtesting.SeedInfo.seed([D53318C28A3652F2:1AAD7DFB05C73AAD]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:143)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:77)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 1967 lines...]
   [junit4] JVM J1: stderr was not 

[jira] [Updated] (SOLR-11853) Solr installer fails on SuSE linux (Make check for used tool "service" compatible with SuSE Linux like OpenSuse or SLES)

[Markus Mandalka (JIRA)]

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

Markus Mandalka updated SOLR-11853:
---
Affects Version/s: 7.5

> Solr installer fails on SuSE linux (Make check for used tool "service" 
> compatible with SuSE Linux like OpenSuse or SLES)
> 
>
> Key: SOLR-11853
> URL: https://issues.apache.org/jira/browse/SOLR-11853
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.0.1, 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5
> Environment: SuSE Linux (SLES & OpenSuSE)
>Reporter: Markus Mandalka
>Priority: Minor
>  Labels: github-import, newbie, patch
> Fix For: 7.6, master (8.0)
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> On current SuSE Linux releases like SLES or OpenSuSE the Solr installer stops 
> with the error message "Script requires the 'service' command".
> This happens because before installation the installer checks if the used 
> command "service" exists by its option "service --version".
> The command line option "--version" doesn't exist for "service" on current 
> SuSE Linux stable releases.
> Since the command "service" is there and has an option "--help", this option 
> can be used as additional fallback.
> So in the pull request i extended the check with "service --help" as second 
> check / fallback before printing this error and exiting.



--
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-13090) Make maxBooleanClauses support system-property override

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13090:


Commit c34f29a4b4149dd0ab8e28cf781a5fb76e5e4272 in lucene-solr's branch 
refs/heads/master from Jason Gerlowski
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c34f29a ]

SOLR-13090: Add sysprop override for maxBooleanClauses


> Make maxBooleanClauses support system-property override
> ---
>
> Key: SOLR-13090
> URL: https://issues.apache.org/jira/browse/SOLR-13090
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (8.0), 7.7
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13090.patch
>
>
> Currently, the {{maxBooleanClauses}} property is specified in most 
> solrconfig's as the hardcoded value "1024".  It'd be nice if we changed our 
> shipped configs so that they instead specified it as 
> {{${solr.max.booleanClauses:1024} This would maintain the current OOTB behavior (maxBooleanClauses would still 
> default to 1024) while adding the ability to update maxBooleanClauses values 
> across the board much more easily.  (I see users want to do this often when 
> they first run up against this limit.)



--
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 issue #305: SOLR-11853: Make check for used tool "service" compa...

[Mandalka]

Github user Mandalka commented on the issue:

https://github.com/apache/lucene-solr/pull/305
  
For future OpenSuSE releases the main issue / need of patch (rest of 
failing steps can be done after installation by adding group and rights) is 
solved by https://github.com/openSUSE/aaa_base/pull/53 which was merged to 
master, but maybe because of very long release live times not for 
former/current SLES.


---

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

[jira] [Commented] (SOLR-11853) Solr installer fails on SuSE linux (Make check for used tool "service" compatible with SuSE Linux like OpenSuse or SLES)

[Markus Mandalka (JIRA)]

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

Markus Mandalka commented on SOLR-11853:


For future OpenSuSE releases the main issue / need of patch is solved by 
[https://github.com/openSUSE/aaa_base/pull/53] but maybe because of very long 
release live times not for former/current SLES.

> Solr installer fails on SuSE linux (Make check for used tool "service" 
> compatible with SuSE Linux like OpenSuse or SLES)
> 
>
> Key: SOLR-11853
> URL: https://issues.apache.org/jira/browse/SOLR-11853
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.0.1, 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5
> Environment: SuSE Linux (SLES & OpenSuSE)
>Reporter: Markus Mandalka
>Priority: Minor
>  Labels: github-import, newbie, patch
> Fix For: 7.6, master (8.0)
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> On current SuSE Linux releases like SLES or OpenSuSE the Solr installer stops 
> with the error message "Script requires the 'service' command".
> This happens because before installation the installer checks if the used 
> command "service" exists by its option "service --version".
> The command line option "--version" doesn't exist for "service" on current 
> SuSE Linux stable releases.
> Since the command "service" is there and has an option "--help", this option 
> can be used as additional fallback.
> So in the pull request i extended the check with "service --help" as second 
> check / fallback before printing this error and exiting.



--
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-13050) SystemLogListener can "lose" record of nodeLost event when node lost is/was .system collection leader

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13050:


Commit b9457b78d573c133e1beeb50cdf1fc786ae0c0f4 in lucene-solr's branch 
refs/heads/master from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b9457b7 ]

SOLR-13050: Fix another test that could accidentally kill the .system leader 
node.
Improve fallback in SystemLogListener when target collection is not present.


> SystemLogListener can "lose" record of nodeLost event when node lost is/was 
> .system collection leader
> -
>
> Key: SOLR-13050
> URL: https://issues.apache.org/jira/browse/SOLR-13050
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13050.test-workaround.patch, 
> jenkins.sarowe__Lucene-Solr-tests-7.x__7104.log.txt
>
>
> A chicken/egg issue of the way the autoscaling SystemLogListener uses the 
> {{.system}} collection to record event history is that in the case of a 
> {{nodeLost}} event for the {{.system}} collection's leader, there is a window 
> of time during leader election where trying to add the "Document" 
> representing that {{nodeLost}} event to the {{.system}} collection can fail.
> This isn't a silently failure: the SystemLogListener, acting the role of a 
> Solr client, is informed that the "add" failed, but it doesn't/can't do much 
> to deal with this situation other then to "log" (to the slf4j Logger) that it 
> wasn't able to add the doc.
> 
> I'm not sure how much of a "real world" impact this has on users, but I 
> noticed the issue while diagnosing a jenkins test failure and wanted to track 
> it.



--
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-13099) Support a new type of unit 'WEEK ' for DateMathParser

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-13099:
---

I've though about week as well, but have been satisfied with the ability to do 
a +7DAY gap from any starting position. 

 

 

> Support a new type of unit 'WEEK ' for DateMathParser
> -
>
> Key: SOLR-13099
> URL: https://issues.apache.org/jira/browse/SOLR-13099
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Haochao Zhuang
>Priority: Major
>
> for convenience purpose, i think a WEEK unit is necessary.



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

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

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

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth

Error Message:
Timeout occured while waiting response from server at: 
https://127.0.0.1:34051/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:34051/solr
at 
__randomizedtesting.SeedInfo.seed([7A4F02805D37A45D:86F5D6B4A5171597]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:661)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:256)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:213)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1110)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkCreateCollection(TestMiniSolrCloudClusterSSL.java:276)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithCollectionCreations(TestMiniSolrCloudClusterSSL.java:264)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithNodeReplacement(TestMiniSolrCloudClusterSSL.java:167)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth(TestMiniSolrCloudClusterSSL.java:129)
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.StatementAdapter.evaluate(StatementAdapter.java:36)
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 

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

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/2603/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-7.x/42/consoleText

[repro] Revision: 2ccb505912f5ee1818112e27518154b606b7512e

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=ForceLeaderTest 
-Dtests.method=testReplicasInLIRNoLeader -Dtests.seed=A3F5576C084DAA87 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=th-TH-u-nu-thai-x-lvariant-TH -Dtests.timezone=Asia/Aqtau 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestSimTriggerIntegration 
-Dtests.method=testNodeMarkersRegistration -Dtests.seed=A3F5576C084DAA87 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=ru-RU -Dtests.timezone=Africa/Asmara -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
302184dd7ff09f091c0290484743929044789e14
[repro] git fetch
[repro] git checkout 2ccb505912f5ee1818112e27518154b606b7512e

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

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

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   TestSimTriggerIntegration
[repro]   ForceLeaderTest
[repro] ant compile-test

[...truncated 3605 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.TestSimTriggerIntegration|*.ForceLeaderTest" 
-Dtests.showOutput=onerror -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=A3F5576C084DAA87 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=ru-RU -Dtests.timezone=Africa/Asmara -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[...truncated 8227 lines...]
   [junit4]   2> 144559 WARN  
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[A3F5576C084DAA87]) [] 
o.a.s.c.AbstractFullDistribZkTestBase ERROR: 
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request. ... Sleeping for 1 seconds before re-try ...
   [junit4]   2> 145560 ERROR 
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[A3F5576C084DAA87]) [] 
o.a.s.c.s.i.CloudSolrClient Request to collection 
[forceleader_lower_terms_collection] failed due to (510) 
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request., retry=0 commError=false errorCode=510 
   [junit4]   2> 145560 INFO  
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[A3F5576C084DAA87]) [] 
o.a.s.c.s.i.CloudSolrClient request was not communication error it seems
   [junit4]   2> 145560 WARN  
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[A3F5576C084DAA87]) [] 
o.a.s.c.AbstractFullDistribZkTestBase ERROR: 
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request. ... Sleeping for 1 seconds before re-try ...
   [junit4]   2> 146579 ERROR 
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[A3F5576C084DAA87]) [] 
o.a.s.c.s.i.CloudSolrClient Request to collection 
[forceleader_lower_terms_collection] failed due to (510) 
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request., retry=0 commError=false errorCode=510 
   [junit4]   2> 146579 INFO  
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[A3F5576C084DAA87]) [] 
o.a.s.c.s.i.CloudSolrClient request was not communication error it seems
   [junit4]   2> 146579 WARN  
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[A3F5576C084DAA87]) [] 
o.a.s.c.AbstractFullDistribZkTestBase ERROR: 
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request. ... Sleeping for 1 seconds before re-try ...
   [junit4]   2> 147580 ERROR 
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[A3F5576C084DAA87]) [] 
o.a.s.c.s.i.CloudSolrClient Request to collection 
[forceleader_lower_terms_collection] failed due to (510) 
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request., retry=0 commError=false errorCode=510 
   [junit4]   2> 147580 INFO  

[jira] [Commented] (SOLR-13099) Support a new type of unit 'WEEK ' for DateMathParser

[JIRA]

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

Jan Høydahl commented on SOLR-13099:


Feel free to attach a patch. Guess it should be doable, but complexities as to 
whether Monday or Sunday is the first day of week will arise.

> Support a new type of unit 'WEEK ' for DateMathParser
> -
>
> Key: SOLR-13099
> URL: https://issues.apache.org/jira/browse/SOLR-13099
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Haochao Zhuang
>Priority: Major
>
> for convenience purpose, i think a WEEK unit is necessary.



--
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: Congratulations to the new Lucene/Solr PMC chair, Cassandra Targett

[Joel Bernstein]

Congratulations Cassandra!

Joel Bernstein
http://joelsolr.blogspot.com/


On Wed, Jan 2, 2019 at 8:39 AM Tommaso Teofili 
wrote:

> Congrats Cassandra!
> Il giorno mer 2 gen 2019 alle ore 12:43 Shalin Shekhar Mangar
>  ha scritto:
> >
> > Congratulations Cassandra!
> >
> > On Mon, Dec 31, 2018 at 1:08 PM Adrien Grand  wrote:
> >>
> >> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache
> >> Vice President position.
> >>
> >> This year we have nominated and elected Cassandra Targett as the
> >> chair, a decision that the board approved in its December 2018
> >> meeting.
> >>
> >> Congratulations, Cassandra!
> >>
> >> --
> >> Adrien
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
> >
> > --
> > Regards,
> > Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[GitHub] lucene-solr issue #531: SOLR-12768

[dsmiley]

Github user dsmiley commented on the issue:

https://github.com/apache/lucene-solr/pull/531
  
The way this field is indexed has been experimental and will remain so for 
a bit.  8.0 will be it's more public debut, after which changing it will be 
more effort than today.  Nonetheless I will make this change clear in 
CHANGES.txt in case someone was using it.


---

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

Re: Congratulations to the new Lucene/Solr PMC chair, Cassandra Targett

[Tommaso Teofili]

Congrats Cassandra!
Il giorno mer 2 gen 2019 alle ore 12:43 Shalin Shekhar Mangar
 ha scritto:
>
> Congratulations Cassandra!
>
> On Mon, Dec 31, 2018 at 1:08 PM Adrien Grand  wrote:
>>
>> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache
>> Vice President position.
>>
>> This year we have nominated and elected Cassandra Targett as the
>> chair, a decision that the board approved in its December 2018
>> meeting.
>>
>> Congratulations, Cassandra!
>>
>> --
>> Adrien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.

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

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 420 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/420/

6 tests failed.
FAILED:  org.apache.lucene.index.Test2BPostings.test

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([355CECFE06839C71:BD08D324A87FF189]:0)
at 
org.apache.lucene.util.ByteBlockPool$DirectTrackingAllocator.getByteBlock(ByteBlockPool.java:103)
at 
org.apache.lucene.util.ByteBlockPool.nextBuffer(ByteBlockPool.java:203)
at 
org.apache.lucene.util.ByteBlockPool.allocSlice(ByteBlockPool.java:258)
at 
org.apache.lucene.index.TermsHashPerField.writeByte(TermsHashPerField.java:203)
at 
org.apache.lucene.index.TermsHashPerField.writeVInt(TermsHashPerField.java:224)
at 
org.apache.lucene.index.FreqProxTermsWriterPerField.addTerm(FreqProxTermsWriterPerField.java:146)
at 
org.apache.lucene.index.TermsHashPerField.add(TermsHashPerField.java:185)
at 
org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:838)
at 
org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:430)
at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:394)
at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:251)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:494)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1616)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1235)
at org.apache.lucene.index.Test2BPostings.test(Test2BPostings.java:73)
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)


FAILED:  
org.apache.lucene.index.TestIndexingSequenceNumbers.testStressConcurrentCommit

Error Message:
this IndexWriter is closed

Stack Trace:
org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:680)
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:694)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3429)
at 
org.apache.lucene.index.TestIndexingSequenceNumbers.testStressConcurrentCommit(TestIndexingSequenceNumbers.java:228)
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 

[jira] [Assigned] (SOLR-6595) Improve error response in case distributed collection cmd fails

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski reassigned SOLR-6595:
-

Assignee: (was: Jason Gerlowski)

> Improve error response in case distributed collection cmd fails
> ---
>
> Key: SOLR-6595
> URL: https://issues.apache.org/jira/browse/SOLR-6595
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.10
> Environment: SolrCloud with Client SSL
>Reporter: Sindre Fiskaa
>Priority: Minor
> Attachments: SOLR-6595.patch
>
>
> Followed the description 
> https://cwiki.apache.org/confluence/display/solr/Enabling+SSL and generated a 
> self signed key pair. Configured a few solr-nodes and used the collection api 
> to crate a new collection. -I get error message when specify the nodes with 
> the createNodeSet param. When I don't use createNodeSet param the collection 
> gets created without error on random nodes. Could this be a bug related to 
> the createNodeSet param?- *Update: It failed due to what turned out to be 
> invalid client certificate on the overseer, and returned the following 
> response:*
> {code:xml}
> 
>   0 name="QTime">185
>   
> org.apache.solr.client.solrj.SolrServerException:IOException occured 
> when talking to server at: https://vt-searchln04:443/solr
>   
> 
> {code}
> *Update: Three problems:*
> # Status=0 when the cmd did not succeed (only ZK was updated, but cores not 
> created due to failing to connect to shard nodes to talk to core admin API).
> # The error printed does not tell which action failed. Would be helpful to 
> either get the msg from the original exception or at least some message 
> saying "Failed to create core, see log on Overseer 
> # State of collection is not clean since it exists as far as ZK is concerned 
> but cores not created. Thus retrying the CREATECOLLECTION cmd would fail. 
> Should Overseer detect error in distributed cmds and rollback changes already 
> made in ZK?



--
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 issue #531: SOLR-12768

[moshebla]

Github user moshebla commented on the issue:

https://github.com/apache/lucene-solr/pull/531
  
I'll add another test-case then.

> I wonder... hmmm... maybe the nest path should always start with a '/'? 
It would seem more correct since paths in general usually start with one, and 
it would also make implementing this case simpler.

Logically, this seems like the more correct way to pursue.
Although, I wonder whether this is the correct time to start this over,
with Solr 8 just around the corner.
WDYT?


---

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

[jira] [Assigned] (SOLR-13038) Overseer actions fail with NoHttpResponseException following a node restart

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski reassigned SOLR-13038:
--

Assignee: (was: Jason Gerlowski)

I hope to revisit this soon, but don't have time to focus on it in the 
immediate future.  So I'm removing myself as the assignee.

I still think this is an important issue to fix though, as it's a continuing 
contributor to test flakiness, as well as production behavior.

> Overseer actions fail with NoHttpResponseException following a node restart
> ---
>
> Key: SOLR-13038
> URL: https://issues.apache.org/jira/browse/SOLR-13038
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13038.patch
>
>
> I noticed recently that a lot of overseer operations fail if they're executed 
> right after a restart of a Solr node.  The failure returns a message like 
> "org.apache.solr.client.solrj.SolrServerException:IOException occured when 
> talking to server at: https://127.0.0.1:62253/solr;.  The logs are a bit more 
> helpful:
> {code}
> org.apache.solr.client.solrj.SolrServerException: IOException occured when 
> talking to server at: https://127.0.0.1:62253/solr
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:657)
>  ~[java/:?]
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
>  ~[java/:?]
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
>  ~[java/:?]
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1260) 
> ~[java/:?]
> at 
> org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:172)
>  ~[java/:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_172]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[?:1.8.0_172]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_172]
> at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
>  ~[metrics-core-3.2.6.jar:3.2.6]
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
>  ~[java/:?]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  [?:1.8.0_172]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  [?:1.8.0_172]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_172]
> Caused by: org.apache.http.NoHttpResponseException: 127.0.0.1:62253 failed to 
> respond
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:141)
>  ~[httpclient-4.5.6.jar:4.5.6]
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
>  ~[httpclient-4.5.6.jar:4.5.6]
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
>  ~[httpcore-4.4.10.jar:4.4.10]
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
>  ~[httpcore-4.4.10.jar:4.4.10]
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
>  ~[httpclient-4.5.6.jar:4.5.6]
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
>  ~[httpcore-4.4.10.jar:4.4.10]
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
>  ~[httpcore-4.4.10.jar:4.4.10]
> at 
> org.apache.solr.util.stats.InstrumentedHttpRequestExecutor.execute(InstrumentedHttpRequestExecutor.java:120)
>  ~[java/:?]
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
>  ~[httpclient-4.5.6.jar:4.5.6]
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185) 
> ~[httpclient-4.5.6.jar:4.5.6]
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) 
> ~[httpclient-4.5.6.jar:4.5.6]
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) 
> ~[httpclient-4.5.6.jar:4.5.6]
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
>  ~[httpclient-4.5.6.jar:4.5.6]
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
>  ~[httpclient-4.5.6.jar:4.5.6]
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
>  ~[httpclient-4.5.6.jar:4.5.6]
> 

[jira] [Commented] (SOLR-6595) Improve error response in case distributed collection cmd fails

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-6595:
---

I'm not going to have much time in the immediate future to finish this up, so I 
wanted to summarize the progress so far:

- the latest patch sets the "status" property to 500 when the "failure" list is 
present and non-empty
- because of this, SolrJ will now throw exceptions in failure cases where it 
previously allowed the request to fail silently.  This causes some tests to 
fail that were passing (incorrectly) before.  I investigated a few examples of 
this, and most were in test setup/cleanup when the expectations were a bit off. 
 There weren't a ton of these failures though and they should be simpler to 
debug thanks to other recent test flakiness improvements.
- I investigated making changes to SolrJ that would attach a NamedList to 
SolrExceptions thrown because of a 500, but didn't pursue that too far.  It's 
probably a separate JIRA anyways. 

> Improve error response in case distributed collection cmd fails
> ---
>
> Key: SOLR-6595
> URL: https://issues.apache.org/jira/browse/SOLR-6595
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.10
> Environment: SolrCloud with Client SSL
>Reporter: Sindre Fiskaa
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-6595.patch
>
>
> Followed the description 
> https://cwiki.apache.org/confluence/display/solr/Enabling+SSL and generated a 
> self signed key pair. Configured a few solr-nodes and used the collection api 
> to crate a new collection. -I get error message when specify the nodes with 
> the createNodeSet param. When I don't use createNodeSet param the collection 
> gets created without error on random nodes. Could this be a bug related to 
> the createNodeSet param?- *Update: It failed due to what turned out to be 
> invalid client certificate on the overseer, and returned the following 
> response:*
> {code:xml}
> 
>   0 name="QTime">185
>   
> org.apache.solr.client.solrj.SolrServerException:IOException occured 
> when talking to server at: https://vt-searchln04:443/solr
>   
> 
> {code}
> *Update: Three problems:*
> # Status=0 when the cmd did not succeed (only ZK was updated, but cores not 
> created due to failing to connect to shard nodes to talk to core admin API).
> # The error printed does not tell which action failed. Would be helpful to 
> either get the msg from the original exception or at least some message 
> saying "Failed to create core, see log on Overseer 
> # State of collection is not clean since it exists as far as ZK is concerned 
> but cores not created. Thus retrying the CREATECOLLECTION cmd would fail. 
> Should Overseer detect error in distributed cmds and rollback changes already 
> made in ZK?



--
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 issue #531: SOLR-12768

[dsmiley]

Github user dsmiley commented on the issue:

https://github.com/apache/lucene-solr/pull/531
  
Looks good.  I thought you were going to test with something to show we 
don't screw it up?  You could search for 'redients' which would have returned 
something before but now should not.

I wonder... hmmm... maybe the nest path should always start with a '/'?  It 
would seem more correct since paths in general usually start with one, and it 
would also make implementing this case simpler.


---

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

[GitHub] lucene-solr issue #531: SOLR-12768

[moshebla]

Github user moshebla commented on the issue:

https://github.com/apache/lucene-solr/pull/531
  
> I think a solution is to build an OR query where one clause has a */ 
prepended to it, and the other has nothing modified and so matches the term 
exactly. WDYT?

Yes that seems correct, and all added unit tests pass.
I just pushed a new commit implementing this.



---

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

[jira] [Created] (SOLR-13099) Support a new type of unit 'WEEK ' for DateMathParser

[Haochao Zhuang (JIRA)]

Haochao Zhuang created SOLR-13099:
-

 Summary: Support a new type of unit 'WEEK ' for DateMathParser
 Key: SOLR-13099
 URL: https://issues.apache.org/jira/browse/SOLR-13099
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Haochao Zhuang


for convenience purpose, i think a WEEK unit is necessary.



--
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-13035) Utilize solr.data.home / solrDataHome in solr.xml to set all writable files in single directory

[JIRA]

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

Jan Høydahl commented on SOLR-13035:


My main point was not to add a 'var' dir in the dist but to make an intuitive 
distinction between binaries and data. {{SOLR_VAR_ROOT}} could default to 
{{$SOLR_TIP}} and thus get {{data}} and {{logs}} directories under root. Of 
course you can set SOLR_HOME, SOLR_LOGS_DIR and PID_DIR today to move 
everything but I understood the title of this JIRA is to make this even easier?

> Utilize solr.data.home / solrDataHome in solr.xml to set all writable files 
> in single directory
> ---
>
> Key: SOLR-13035
> URL: https://issues.apache.org/jira/browse/SOLR-13035
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Amrit Sarkar
>Priority: Major
> Attachments: SOLR-13035.patch, SOLR-13035.patch
>
>
> {{solr.data.home}} system property or {{solrDataHome}} in _solr.xml_ is 
> already available as per SOLR-6671.
> The writable content in Solr are index files, core properties, and ZK data if 
> embedded zookeeper is started in SolrCloud mode. It would be great if all 
> writable content can come under the same directory to have separate READ-ONLY 
> and WRITE-ONLY directories.
> It can then also solve official docker Solr image issues:
> https://github.com/docker-solr/docker-solr/issues/74
> https://github.com/docker-solr/docker-solr/issues/133



--
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: Congratulations to the new Lucene/Solr PMC chair, Cassandra Targett

[Shalin Shekhar Mangar]

Congratulations Cassandra!

On Mon, Dec 31, 2018 at 1:08 PM Adrien Grand  wrote:

> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache
> Vice President position.
>
> This year we have nominated and elected Cassandra Targett as the
> chair, a decision that the board approved in its December 2018
> meeting.
>
> Congratulations, Cassandra!
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Regards,
Shalin Shekhar Mangar.

[jira] [Commented] (SOLR-13050) SystemLogListener can "lose" record of nodeLost event when node lost is/was .system collection leader

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13050:
--

No components depend on the events being stored in the {{.system}} collection 
because this listener is optional (it's added by default to all new triggers 
but can be removed), so this failure should have no impact on proper 
functioning of autoscaling.

However, there may be other tests that depend on this functionality - several 
tests verify that certain events are present but I'm not sure if they all make 
sure not to kill the {{.system}} leader, so I'm going to check this.

> SystemLogListener can "lose" record of nodeLost event when node lost is/was 
> .system collection leader
> -
>
> Key: SOLR-13050
> URL: https://issues.apache.org/jira/browse/SOLR-13050
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13050.test-workaround.patch, 
> jenkins.sarowe__Lucene-Solr-tests-7.x__7104.log.txt
>
>
> A chicken/egg issue of the way the autoscaling SystemLogListener uses the 
> {{.system}} collection to record event history is that in the case of a 
> {{nodeLost}} event for the {{.system}} collection's leader, there is a window 
> of time during leader election where trying to add the "Document" 
> representing that {{nodeLost}} event to the {{.system}} collection can fail.
> This isn't a silently failure: the SystemLogListener, acting the role of a 
> Solr client, is informed that the "add" failed, but it doesn't/can't do much 
> to deal with this situation other then to "log" (to the slf4j Logger) that it 
> wasn't able to add the doc.
> 
> I'm not sure how much of a "real world" impact this has on users, but I 
> noticed the issue while diagnosing a jenkins test failure and wanted to track 
> it.



--
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-13050) SystemLogListener can "lose" record of nodeLost event when node lost is/was .system collection leader

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  reassigned SOLR-13050:


Assignee: Andrzej Bialecki 

> SystemLogListener can "lose" record of nodeLost event when node lost is/was 
> .system collection leader
> -
>
> Key: SOLR-13050
> URL: https://issues.apache.org/jira/browse/SOLR-13050
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13050.test-workaround.patch, 
> jenkins.sarowe__Lucene-Solr-tests-7.x__7104.log.txt
>
>
> A chicken/egg issue of the way the autoscaling SystemLogListener uses the 
> {{.system}} collection to record event history is that in the case of a 
> {{nodeLost}} event for the {{.system}} collection's leader, there is a window 
> of time during leader election where trying to add the "Document" 
> representing that {{nodeLost}} event to the {{.system}} collection can fail.
> This isn't a silently failure: the SystemLogListener, acting the role of a 
> Solr client, is informed that the "add" failed, but it doesn't/can't do much 
> to deal with this situation other then to "log" (to the slf4j Logger) that it 
> wasn't able to add the doc.
> 
> I'm not sure how much of a "real world" impact this has on users, but I 
> noticed the issue while diagnosing a jenkins test failure and wanted to track 
> it.



--
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: Congratulations to the new Lucene/Solr PMC chair, Cassandra Targett

[Alan Woodward]

Congratulations Cassandra!

> On 2 Jan 2019, at 10:12, jim ferenczi  > wrote:
> 
> Congrats Cassandra !
> 
> Le mer. 2 janv. 2019 à 11:02, Christine Poerschke (BLOOMBERG/ LONDON) 
> mailto:cpoersc...@bloomberg.net>> a écrit :
> Congratulations!
> 
> Christine
> 
> From: dev@lucene.apache.org  At: 12/31/18 
> 07:38:51
> To:  dev@lucene.apache.org 
> Subject: Congratulations to the new Lucene/Solr PMC chair, Cassandra Targett
> 
> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache
> Vice President position.
> 
> This year we have nominated and elected Cassandra Targett as the
> chair, a decision that the board approved in its December 2018
> meeting.
> 
> Congratulations, Cassandra!
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 

Re: Congratulations to the new Lucene/Solr PMC chair, Cassandra Targett

[jim ferenczi]

Congrats Cassandra !

Le mer. 2 janv. 2019 à 11:02, Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> a écrit :

> Congratulations!
>
> Christine
>
> From: dev@lucene.apache.org At: 12/31/18 07:38:51
> To: dev@lucene.apache.org
> Subject: Congratulations to the new Lucene/Solr PMC chair, Cassandra
> Targett
>
> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache
> Vice President position.
>
> This year we have nominated and elected Cassandra Targett as the
> chair, a decision that the board approved in its December 2018
> meeting.
>
> Congratulations, Cassandra!
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>

[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk1.8.0) - Build # 1004 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/1004/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.testNodeLostTriggerRestoreState

Error Message:
The trigger did not fire at all

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


FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.testNodeMarkersRegistration

Error Message:
Path /autoscaling/nodeAdded/127.0.0.1:10044_solr should have been deleted

Stack Trace:

Re:Congratulations to the new Lucene/Solr PMC chair, Cassandra Targett

[Christine Poerschke (BLOOMBERG/ LONDON)]

Congratulations!

Christine

From: dev@lucene.apache.org At: 12/31/18 07:38:51To:  dev@lucene.apache.org
Subject: Congratulations to the new Lucene/Solr PMC chair, Cassandra Targett

Every year, the Lucene PMC rotates the Lucene PMC chair and Apache
Vice President position.

This year we have nominated and elected Cassandra Targett as the
chair, a decision that the board approved in its December 2018
meeting.

Congratulations, Cassandra!

-- 
Adrien

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

[jira] [Commented] (SOLR-13035) Utilize solr.data.home / solrDataHome in solr.xml to set all writable files in single directory

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-13035:
--

Why should there be a "var" directory under the unzipped solr? "var" doesn't 
mean anything on windows, for example. Most datastores ship with a logs and 
data directory right under the unzipped root. I think we should do the same and 
not introduce new environment variables. Also, it should be possible to point 
data and logs to separate mount points which a new SOLR_VAR_ROOT doesn't hinder 
but doesn't help with too.

If someone wants to move all such writable directories under one then they can 
set multiple variables (which already exist and are relatively well known) or 
they can mount to multiple places. This will likely be done by the docker-solr 
project so it is not like everyone has to make this decision. I'd be okay going 
with your proposal if getting rid of the myriad of properties we already have 
is part of the plan but if not, then adding one more just causes more confusion 
I feel.

> Utilize solr.data.home / solrDataHome in solr.xml to set all writable files 
> in single directory
> ---
>
> Key: SOLR-13035
> URL: https://issues.apache.org/jira/browse/SOLR-13035
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Amrit Sarkar
>Priority: Major
> Attachments: SOLR-13035.patch, SOLR-13035.patch
>
>
> {{solr.data.home}} system property or {{solrDataHome}} in _solr.xml_ is 
> already available as per SOLR-6671.
> The writable content in Solr are index files, core properties, and ZK data if 
> embedded zookeeper is started in SolrCloud mode. It would be great if all 
> writable content can come under the same directory to have separate READ-ONLY 
> and WRITE-ONLY directories.
> It can then also solve official docker Solr image issues:
> https://github.com/docker-solr/docker-solr/issues/74
> https://github.com/docker-solr/docker-solr/issues/133



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

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

[jira] [Resolved] (LUCENE-8627) TestSearchAfter.testQueries() failure

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi resolved LUCENE-8627.
--
   Resolution: Fixed
Fix Version/s: master (8.0)

The test fails because the hit count is not tracked accurately. I pushed a fix 
that ensures that hit counts are accurate in order to be able to compare them 
during the tests.
Thanks [~steve_rowe]. 

> TestSearchAfter.testQueries() failure
> -
>
> Key: LUCENE-8627
> URL: https://issues.apache.org/jira/browse/LUCENE-8627
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>Priority: Major
> Fix For: master (8.0)
>
>
> From [https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1735], 
> reproduces 10/10 iterations for me:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSearchAfter 
> -Dtests.method=testQueries -Dtests.seed=C0154BFB98528228 -Dtests.multiplier=2 
> -Dtests.nightly=true -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
>  -Dtests.locale=sr-ME -Dtests.timezone=Africa/Timbuktu -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.34s J2 | TestSearchAfter.testQueries <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1082> but 
> was:<1000>
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([C0154BFB98528228:9C9B8720823B3786]:0)
>[junit4]>at 
> org.apache.lucene.search.TestSearchAfter.assertPage(TestSearchAfter.java:268)
>[junit4]>at 
> org.apache.lucene.search.TestSearchAfter.assertQuery(TestSearchAfter.java:260)
>[junit4]>at 
> org.apache.lucene.search.TestSearchAfter.testQueries(TestSearchAfter.java:183)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=CheapBastard, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@6f9a6df3),
>  locale=sr-ME, timezone=Africa/Timbuktu
>[junit4]   2> NOTE: Linux 4.4.0-137-generic amd64/Oracle Corporation 
> 1.8.0_191 (64-bit)/cpus=4,threads=1,free=174481080,total=519045120
> {noformat}



--
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-13098) HttpParamDelegationTokenPlugin doesn't set the user Principal

[Noble Paul (JIRA)]

Noble Paul created SOLR-13098:
-

 Summary: HttpParamDelegationTokenPlugin doesn't set the user 
Principal
 Key: SOLR-13098
 URL: https://issues.apache.org/jira/browse/SOLR-13098
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
 Environment: {{TestSolrCloudWithSecureImpersonation.testForwarding}} 
fails
Reporter: Noble Paul






--
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-13098) HttpParamDelegationTokenPlugin doesn't set the user Principal

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-13098:
--
Environment: (was: 
{{TestSolrCloudWithSecureImpersonation.testForwarding}} fails)

> HttpParamDelegationTokenPlugin doesn't set the user Principal
> -
>
> Key: SOLR-13098
> URL: https://issues.apache.org/jira/browse/SOLR-13098
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>




--
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-13098) HttpParamDelegationTokenPlugin doesn't set the user Principal

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-13098:
--
Description: {{TestSolrCloudWithSecureImpersonation.testForwarding}} fails

> HttpParamDelegationTokenPlugin doesn't set the user Principal
> -
>
> Key: SOLR-13098
> URL: https://issues.apache.org/jira/browse/SOLR-13098
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> {{TestSolrCloudWithSecureImpersonation.testForwarding}} fails



--
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-BadApples-7.x-Linux (64bit/jdk-12-ea+23) - Build # 141 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/141/
Java: 64bit/jdk-12-ea+23 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.lucene.index.TestTieredMergePolicy

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

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


FAILED:  
org.apache.lucene.index.TestTieredMergePolicy.testForcedMergesRespectSegSize

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([78B64ABB435C245]:0)


FAILED:  
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader

Error Message:
Doc with id=4 not found in 
http://127.0.0.1:36553/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:36553/solr/outOfSyncReplicasCannotBecomeLeader-false due to: 
Path not found: /id; rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([7D1E5958C390D36B:3F5794800F7DC51]: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 

[jira] [Commented] (LUCENE-8627) TestSearchAfter.testQueries() failure

[ASF subversion and git services (JIRA)]

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

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

Commit 7c70365811bb2800bdaf39302e187e8a9a180872 in lucene-solr's branch 
refs/heads/master from Jim Ferenczi
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7c70365 ]

LUCENE-8627: Fix SearchAfter#testQueries to always count the number of hits 
accurately.


> TestSearchAfter.testQueries() failure
> -
>
> Key: LUCENE-8627
> URL: https://issues.apache.org/jira/browse/LUCENE-8627
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>Priority: Major
>
> From [https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1735], 
> reproduces 10/10 iterations for me:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSearchAfter 
> -Dtests.method=testQueries -Dtests.seed=C0154BFB98528228 -Dtests.multiplier=2 
> -Dtests.nightly=true -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
>  -Dtests.locale=sr-ME -Dtests.timezone=Africa/Timbuktu -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.34s J2 | TestSearchAfter.testQueries <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1082> but 
> was:<1000>
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([C0154BFB98528228:9C9B8720823B3786]:0)
>[junit4]>at 
> org.apache.lucene.search.TestSearchAfter.assertPage(TestSearchAfter.java:268)
>[junit4]>at 
> org.apache.lucene.search.TestSearchAfter.assertQuery(TestSearchAfter.java:260)
>[junit4]>at 
> org.apache.lucene.search.TestSearchAfter.testQueries(TestSearchAfter.java:183)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=CheapBastard, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@6f9a6df3),
>  locale=sr-ME, timezone=Africa/Timbuktu
>[junit4]   2> NOTE: Linux 4.4.0-137-generic amd64/Oracle Corporation 
> 1.8.0_191 (64-bit)/cpus=4,threads=1,free=174481080,total=519045120
> {noformat}



--
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