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

[Policeman Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 62658 lines...]
[repro] Jenkins log URL: 
https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/465/consoleText

[repro] Revision: 9b7e35e69b694d9006c0964ae7a26ed2694ea055

[repro] Ant options: "-Dargs=-XX:-UseCompressedOops -XX:+UseSerialGC"
[repro] No "reproduce with" lines found; exiting.

[...truncated 8 lines...]
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+43) - Build # 21550 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21550/
Java: 64bit/jdk-10-ea+43 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:45883/solr/MoveReplicaHDFSTest_failed_coll_true, 
http://127.0.0.1:45151/solr/MoveReplicaHDFSTest_failed_coll_true]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:45883/solr/MoveReplicaHDFSTest_failed_coll_true, 
http://127.0.0.1:45151/solr/MoveReplicaHDFSTest_failed_coll_true]
at 
__randomizedtesting.SeedInfo.seed([235AE77B904BDE1:A8F87D850ED76831]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:462)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:991)
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.query(SolrClient.java:942)
at 
org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:309)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 161 - Still Unstable

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.CollectionsAPIAsyncDistributedZkTest.testAsyncRequests

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:33622/solr/myalias, 
http://127.0.0.1:33940/solr/myalias]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:33622/solr/myalias, 
http://127.0.0.1:33940/solr/myalias]
at 
__randomizedtesting.SeedInfo.seed([9CCB1EDD4FB4:788F0F84B875016B]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:462)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
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.query(SolrClient.java:942)
at 
org.apache.solr.cloud.api.collections.CollectionsAPIAsyncDistributedZkTest.testAsyncRequests(CollectionsAPIAsyncDistributedZkTest.java:166)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[jira] [Commented] (LUCENE-8176) HttpReplicatorTest sometimes fails with leaked thread

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-8176:
--

Giving that {{org.eclipse.jetty.io.SelectorManager.doStart()}} creates 
{{ReservedThreadExecutor}} which occurs in the stale stacktrace, the suite 
timeout should be raised above 1 min which is default idle time for {{RTE}}, 
during that minute it may ignore {{interrupt()}} that causes this failure.  

> HttpReplicatorTest sometimes fails with leaked thread
> -
>
> Key: LUCENE-8176
> URL: https://issues.apache.org/jira/browse/LUCENE-8176
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
>
> I can't reproduce it locally when beasting thousands of times but it occurs 
> on the Elastic CI. The logs look like this:
> {noformat}
> 08:56:28[junit4] Suite: 
> org.apache.lucene.replicator.http.HttpReplicatorTest
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:34.282:INFO::TEST-HttpReplicatorTest.testBasic-seed#[74212B823E917AF0]: 
> Logging initialized @4074ms to org.eclipse.jetty.util.log.StdErrLog
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:34.416:INFO:oejs.Server:TEST-HttpReplicatorTest.testBasic-seed#[74212B823E917AF0]:
>  jetty-9.4.8.v20171121, build timestamp: 2017-11-22T07:27:37+10:00, git hash: 
> 82b8fb23f757335bb3329d540ce37a2a2615f0a8
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:34.449:INFO:oejs.session:TEST-HttpReplicatorTest.testBasic-seed#[74212B823E917AF0]:
>  DefaultSessionIdManager workerName=node0
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:34.449:INFO:oejs.session:TEST-HttpReplicatorTest.testBasic-seed#[74212B823E917AF0]:
>  No SessionScavenger set, using defaults
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:34.454:INFO:oejs.session:TEST-HttpReplicatorTest.testBasic-seed#[74212B823E917AF0]:
>  Scavenging every 60ms
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:34.509:INFO:oejs.AbstractConnector:TEST-HttpReplicatorTest.testBasic-seed#[74212B823E917AF0]:
>  Started ServerConnector@7d0c3601{HTTP/1.1,[http/1.1]}{127.0.0.1:40696}
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:34.510:INFO:oejs.Server:TEST-HttpReplicatorTest.testBasic-seed#[74212B823E917AF0]:
>  Started @4301ms
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:35.236:INFO:oejs.AbstractConnector:TEST-HttpReplicatorTest.testBasic-seed#[74212B823E917AF0]:
>  Stopped ServerConnector@7d0c3601{HTTP/1.1,[http/1.1]}{127.0.0.1:0}
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:35.239:INFO:oejs.session:TEST-HttpReplicatorTest.testBasic-seed#[74212B823E917AF0]:
>  Stopped scavenging
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:35.258:INFO:oejs.Server:TEST-HttpReplicatorTest.testServerErrors-seed#[74212B823E917AF0]:
>  jetty-9.4.8.v20171121, build timestamp: 2017-11-22T07:27:37+10:00, git hash: 
> 82b8fb23f757335bb3329d540ce37a2a2615f0a8
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:35.260:INFO:oejs.session:TEST-HttpReplicatorTest.testServerErrors-seed#[74212B823E917AF0]:
>  DefaultSessionIdManager workerName=node0
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:35.260:INFO:oejs.session:TEST-HttpReplicatorTest.testServerErrors-seed#[74212B823E917AF0]:
>  No SessionScavenger set, using defaults
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:35.260:INFO:oejs.session:TEST-HttpReplicatorTest.testServerErrors-seed#[74212B823E917AF0]:
>  Scavenging every 66ms
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:35.262:INFO:oejs.AbstractConnector:TEST-HttpReplicatorTest.testServerErrors-seed#[74212B823E917AF0]:
>  Started ServerConnector@31668a1{HTTP/1.1,[http/1.1]}{127.0.0.1:43769}
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:35.262:INFO:oejs.Server:TEST-HttpReplicatorTest.testServerErrors-seed#[74212B823E917AF0]:
>  Started @5054ms
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:35.332:INFO:oejs.AbstractConnector:TEST-HttpReplicatorTest.testServerErrors-seed#[74212B823E917AF0]:
>  Stopped ServerConnector@31668a1{HTTP/1.1,[http/1.1]}{127.0.0.1:0}
> 08:56:28[junit4]   2> 2018-02-15 
> 18:55:35.333:INFO:oejs.session:TEST-HttpReplicatorTest.testServerErrors-seed#[74212B823E917AF0]:
>  Stopped scavenging
> 08:56:28[junit4]   2> 2018-02-15 
> 18:56:05.331:WARN:oejut.QueuedThreadPool:TEST-HttpReplicatorTest.testServerErrors-seed#[74212B823E917AF0]:
>  QueuedThreadPool@qtp1066862162{STOPPING,8<=8<=1,i=0,q=1} Couldn't stop 
> Thread[qtp1066862162-31,5,TGRP-HttpReplicatorTest]
> 08:56:28[junit4]   2> Feb 15, 2018 8:56:05 AM 
> com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
> 08:56:28[junit4]   2> WARNING: Will linger awaiting termination of 1 
> leaked thread(s).
> 08:56:28[junit4]   2> Feb 15, 2018 8:56:25 AM 
> com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
> 

[jira] [Resolved] (SOLR-12027) ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.search.join.BlockJoinFacetDistribTest

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev resolved SOLR-12027.
-
   Resolution: Fixed
 Assignee: Mikhail Khludnev
Fix Version/s: 7.3

> ThreadLeakError: 1 thread leaked from SUITE scope at 
> org.apache.solr.search.join.BlockJoinFacetDistribTest
> --
>
> Key: SOLR-12027
> URL: https://issues.apache.org/jira/browse/SOLR-12027
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR-12027.patch, SOLR-12027.patch, 
> jetty-threadleak-problem-still.txt, jetty-threadleak-problem.txt
>
>
> I tried to look into the sub. The symptoms looks like. 
> {code}
> WARN  (jetty-closer-2-thread-2) [] o.e.j.u.t.QueuedThreadPool 
> QueuedThreadPool@qtp860938026{STOPPING,8<=9<=1,i=0,q=1} Couldn't stop 
> Thread[qtp860938
> {code}
> The thread successfully handled one request before. Then we have:
> {code}
>  2> Feb 23, 2018 11:20:41 PM 
> com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
>   2> SEVERE: 1 thread leaked from SUITE scope at 
> org.apache.solr.search.join.BlockJoinFacetDistribTest: 
>   2>1) Thread[id=76, name=qtp860938026-76, state=TIMED_WAITING, 
> group=TGRP-BlockJoinFacetDistribTest]
>   2> at sun.misc.Unsafe.park(Native Method)
>   2> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>   2> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
>   2> at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.reservedWait(ReservedThreadExecutor.java:308)
>   2> at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:373)
>   2> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
>   2> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
>   2> at java.lang.Thread.run(Thread.java:745)
> {code}
> and then
> {code}
>   2> SEVERE: There are still zombie threads that couldn't be terminated:
>   2>1) Thread[id=76, name=qtp860938026-76, state=TIMED_WAITING, 
> group=TGRP-BlockJoinFacetDistribTest]
>   2> at sun.misc.Unsafe.park(Native Method)
>   2> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> ...
> [23:19:41.186] ERROR   0.00s | BlockJoinFacetDistribTest (suite) <<<
>> Throwable #1: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 
> thread leaked from SUITE scope at 
> org.apache.solr.search.join.BlockJoinFacetDistribTest: 
>>1) Thread[id=76, name=qtp860938026-76, state=TIMED_WAITING, 
> group=TGRP-BlockJoinFacetDistribTest]
>> at sun.misc.Unsafe.park(Native Method)
>> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
>> at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.reservedWait(ReservedThreadExecutor.java:308)
> {code} 
> This also happen to other tests as well, not deterministic, but more or less 
> is reproduced with {{ant beast}}.



--
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: Test failures are out of control......

[Dawid Weiss]

You can also increase the suite timeout for a particular test with
@TimeoutSuite(...) (although making it too long doesn't seem right
too, even nightlies should terminate in a sensible time).

D.

On Tue, Feb 27, 2018 at 11:37 PM, Karl Wright  wrote:
> It succeeds but it takes too long, so I committed a reduction in the number
> of iterations that are attempted for nightly from 20 to 5.  That
> should make it pass reliably.
>
> Karl
>
>
> On Tue, Feb 27, 2018 at 3:52 PM, Erick Erickson 
> wrote:
>>
>> Karl:
>>
>> Let us know if you can't get this to fail locally, we can turn it back
>> on on Jenkins as long as it's getting active attention.
>>
>> Erick
>>
>> On Tue, Feb 27, 2018 at 12:40 PM, Karl Wright  wrote:
>> > I looked at the Geo3d failures; these are timeouts exclusively.  I
>> > suspect
>> > we're seeing a test issue.  Will try to correct.
>> >
>> > Karl
>> >
>> >
>> > On Tue, Feb 27, 2018 at 1:51 PM, Chris Hostetter
>> > 
>> > wrote:
>> >>
>> >> : The most interesting bit is probably here...
>> >> :
>> >> :   http://fucit.org/solr-jenkins-reports/failure-report.html
>> >>
>> >> FYI:
>> >>
>> >> I realized this morning that the "Suite Runs" counts were being
>> >> artificially inflated for suites that are frequently SKIPPED (either
>> >> because they are @Nighly or @Slow and not run by all jenkins jobs).
>> >> I've
>> >> now fixed this, so at a glance the "suite level" failure rates are
>> >> much higher today then they have been if you looked at it in the past.
>> >>
>> >> It means it's also now possible for a Suite failure rate to be greater
>> >> then 100%, because sometimes it's reporting multiple suite level
>> >> failures
>> >> for a single run.
>> >>
>> >>
>> >> Other follow up on some previous comments...
>> >>
>> >> : 1) there's some noise inthe '7days' data because I wasn't accounting
>> >> for
>> >> : the way jenkins reports some types of failure -- that will gradually
>> >> clean
>> >> : itself up
>> >>
>> >> ...some of these "Class: xml" failures are still visible in the report
>> >> but
>> >> should drop off over the next few days
>> >>
>> >> : 2) I think i've been been blocked by builds.apache.org, so at the
>> >> moment
>> >> : the data seems to just be from the sarowe & policeman jenkins
>> >> failures.
>> >>
>> >> ...this is fixed.
>> >>
>> >> : 3) allthough the system is archiving the past 7 days worth of jenkins
>> >> logs
>> >> : for any jobs with failures, there is currently no easy way to
>> >> download
>> >> : the relevant log(s) from that failure report -- you currently have to
>> >>
>> >> ...this is also fixed.  now if you click on any row in the test you'll
>> >> get
>> >> a pop up showing you a link to all the job-data dirs that recorded a
>> >> failure on that report view.  The most recent jobs are listed first.
>> >>
>> >>
>> >>
>> >> -Hoss
>> >> http://www.lucidworks.com/
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1703 - Still unstable!

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
4 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=18315, name=jetty-launcher-2990-thread-1-SendThread(127.0.0.1:54645), 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at java.lang.Thread.sleep(Native Method) at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
 at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000)   
  at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)   
 2) Thread[id=18316, name=jetty-launcher-2990-thread-1-EventThread, 
state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)
3) Thread[id=18317, 
name=jetty-launcher-2990-thread-2-SendThread(127.0.0.1:54645), 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at java.lang.Thread.sleep(Native Method) at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
 at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000)   
  at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)   
 4) Thread[id=18318, name=jetty-launcher-2990-thread-2-EventThread, 
state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 4 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=18315, 
name=jetty-launcher-2990-thread-1-SendThread(127.0.0.1:54645), 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)
   2) Thread[id=18316, name=jetty-launcher-2990-thread-1-EventThread, 
state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)
   3) Thread[id=18317, 
name=jetty-launcher-2990-thread-2-SendThread(127.0.0.1:54645), 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)
   4) Thread[id=18318, name=jetty-launcher-2990-thread-2-EventThread, 
state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)
at __randomizedtesting.SeedInfo.seed([391702F176416E7D]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=18315, name=jetty-launcher-2990-thread-1-SendThread(127.0.0.1:54645), 
state=TIMED_WAITING, 

[jira] [Commented] (SOLR-9510) child level facet exclusions

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-9510:


Thank you, [~osavrasov]] I've just attached [^SOLR_9510.patch]. It fixes the 
case with multiple tags (find zeroTag), asserts some edge cases. I'll copypaste 
more to exclusion handling. 

> child level facet exclusions
> 
>
> Key: SOLR-9510
> URL: https://issues.apache.org/jira/browse/SOLR-9510
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, faceting, query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-9510.patch, SOLR_9510.patch, SOLR_9510.patch, 
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, 
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch
>
>
> h2. Challenge
> * Since SOLR-5743 achieved block join child level facets with counts roll-up 
> to parents, there is a demand for filter exclusions. 
> h2. Context
> * Then, it's worth to consider JSON Facets as an engine for this 
> functionality rather than support a separate component. 
> * During a discussion in SOLR-8998 [a solution for block join with child 
> level 
> exclusion|https://issues.apache.org/jira/browse/SOLR-8998?focusedCommentId=15487095=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15487095]
>  has been found.  
>
> h2. Proposal
> It's proposed to provide a bit of syntax sugar to make it user friendly, 
> believe it or not.
> h2. List of improvements
> * introducing a local parameter {{filters}} for {{\{!parent}} query parser 
> referring to _multiple_ filters queries via parameter name: {{\{!parent 
> filters=$child.fq ..}..=color:Red=size:XL}} 
> these _filters_ are intersected with a child query supplied as a subordinate 
> clause.
> * introducing {{\{!filters params=$child.fq excludeTags=color 
> v=$subq}=text:word={!tag=color}color:Red=size:XL}} it 
> intersects a subordinate clause (here it's {{subq}} param, and the trick is 
> to refer to the same query from {{\{!parent}}}), with multiple filters 
> supplied via parameter name {{params=$child.fq}}, it also supports 
> {{excludeTags}}.
> h2. Notes
> Regarding the latter parser, the alternative approach might be to move into 
> {{domain:\{..}}} instruction of json facet. From the implementation 
> perspective, it's desired to optimize with bitset processing, however I 
> suppose it's might be deferred until some initial level of maturity. 
> h2. Example
> {code}
> q={!parent which=type_s:book filters=$child.fq 
> v=$childquery}=comment_t:good={!tag=author}author_s:yonik={!tag=stars}stars_i:(5
>  3)=json=on={
> comments_for_author:{
>   type:query,
>   q:"{!filters params=$child.fq excludeTags=author v=$childquery}",
>   "//note":"author filter is excluded",
>   domain:{
>  blockChildren:"type_s:book",
>  "//":"applying filters here might be more promising"
>}, facet:{
>authors:{
>   type:terms,
>   field:author_s,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>}
> } ,
> comments_for_stars:{
>   type:query,
>  q:"{!filters params=$child.fq excludeTags=stars v=$childquery}",
>   "//note":"stars_i filter is excluded",
>   domain:{
>  blockChildren:"type_s:book"
>}, facet:{
>stars:{
>   type:terms,
>   field:stars_i,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>   }
> }
> }
> {code} 
> Votes? Opinions?



--
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-9510) child level facet exclusions

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9510:
---
Attachment: SOLR_9510.patch

> child level facet exclusions
> 
>
> Key: SOLR-9510
> URL: https://issues.apache.org/jira/browse/SOLR-9510
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, faceting, query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-9510.patch, SOLR_9510.patch, SOLR_9510.patch, 
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, 
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch
>
>
> h2. Challenge
> * Since SOLR-5743 achieved block join child level facets with counts roll-up 
> to parents, there is a demand for filter exclusions. 
> h2. Context
> * Then, it's worth to consider JSON Facets as an engine for this 
> functionality rather than support a separate component. 
> * During a discussion in SOLR-8998 [a solution for block join with child 
> level 
> exclusion|https://issues.apache.org/jira/browse/SOLR-8998?focusedCommentId=15487095=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15487095]
>  has been found.  
>
> h2. Proposal
> It's proposed to provide a bit of syntax sugar to make it user friendly, 
> believe it or not.
> h2. List of improvements
> * introducing a local parameter {{filters}} for {{\{!parent}} query parser 
> referring to _multiple_ filters queries via parameter name: {{\{!parent 
> filters=$child.fq ..}..=color:Red=size:XL}} 
> these _filters_ are intersected with a child query supplied as a subordinate 
> clause.
> * introducing {{\{!filters params=$child.fq excludeTags=color 
> v=$subq}=text:word={!tag=color}color:Red=size:XL}} it 
> intersects a subordinate clause (here it's {{subq}} param, and the trick is 
> to refer to the same query from {{\{!parent}}}), with multiple filters 
> supplied via parameter name {{params=$child.fq}}, it also supports 
> {{excludeTags}}.
> h2. Notes
> Regarding the latter parser, the alternative approach might be to move into 
> {{domain:\{..}}} instruction of json facet. From the implementation 
> perspective, it's desired to optimize with bitset processing, however I 
> suppose it's might be deferred until some initial level of maturity. 
> h2. Example
> {code}
> q={!parent which=type_s:book filters=$child.fq 
> v=$childquery}=comment_t:good={!tag=author}author_s:yonik={!tag=stars}stars_i:(5
>  3)=json=on={
> comments_for_author:{
>   type:query,
>   q:"{!filters params=$child.fq excludeTags=author v=$childquery}",
>   "//note":"author filter is excluded",
>   domain:{
>  blockChildren:"type_s:book",
>  "//":"applying filters here might be more promising"
>}, facet:{
>authors:{
>   type:terms,
>   field:author_s,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>}
> } ,
> comments_for_stars:{
>   type:query,
>  q:"{!filters params=$child.fq excludeTags=stars v=$childquery}",
>   "//note":"stars_i filter is excluded",
>   domain:{
>  blockChildren:"type_s:book"
>}, facet:{
>stars:{
>   type:terms,
>   field:stars_i,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>   }
> }
> }
> {code} 
> Votes? Opinions?



--
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-Linux (64bit/jdk-10-ea+43) - Build # 1444 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1444/
Java: 64bit/jdk-10-ea+43 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingSorting

Error Message:
Should have exactly 4 documents returned expected:<4> but was:<3>

Stack Trace:
java.lang.AssertionError: Should have exactly 4 documents returned expected:<4> 
but was:<3>
at 
__randomizedtesting.SeedInfo.seed([86A9F7D8432A477E:9891FFD03F81FDFE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.checkSortOrder(DocValuesNotIndexedTest.java:260)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingSorting(DocValuesNotIndexedTest.java:245)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[jira] [Commented] (SOLR-9467) Document Transformer to Remove Fields

[Yeo Zheng Lin (JIRA)]

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

Yeo Zheng Lin commented on SOLR-9467:
-

So far we still do not manage to have this feature in Solr yet?

 

> Document Transformer to Remove Fields
> -
>
> Key: SOLR-9467
> URL: https://issues.apache.org/jira/browse/SOLR-9467
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Affects Versions: 6.2
>Reporter: Gus Heck
>Priority: Major
> Attachments: SOLR-9467.patch, SOLR-9467.patch
>
>
> Given that SOLR-3191 has become bogged down and inactive, evidently stuck in 
> low level details, and since I have wished several times for some way to just 
> get that one big field out of my results to improve transfer times without 
> making a big brittle list of all my other fields. I'd like to propose a 
> DocumentTransformer that accomplishes this.
> It would look something like this:
> {code}=*,[fl.rm v="title"]{code} 
> Since removing one field with a known name is probably the most common case 
> I'd like to start by keeping this simple, and if further features like globs 
> or lists of fields are desired, subsequent Jira tickets can be opened to add 
> them. Not attached to specifics here, only looking to keep things simple and 
> solve the key use case. If you don't like fl.rm as a name for a transformer, 
> suggest a better one (for example). 



--
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-MacOSX (64bit/jdk-9) - Build # 478 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/478/
Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

No tests ran.

Build Log:
[...truncated 1790 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/core/test/temp/junit4-J1-20180228_025512_93913820296029874714728.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/core/test/temp/junit4-J0-20180228_025512_93913414710214631717314.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 281 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/test-framework/test/temp/junit4-J1-20180228_030143_6751559168535778436705.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 9 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/test-framework/test/temp/junit4-J0-20180228_030143_67517581497912233142245.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 1062 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/analysis/common/test/temp/junit4-J0-20180228_030258_40912439438865995101752.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/analysis/common/test/temp/junit4-J1-20180228_030258_4096912125331010198367.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 236 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/analysis/icu/test/temp/junit4-J0-20180228_030532_2606169641926448588294.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/analysis/icu/test/temp/junit4-J1-20180228_030532_26118425165378675925089.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 253 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/analysis/kuromoji/test/temp/junit4-J0-20180228_030545_59818213592869154722364.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/analysis/kuromoji/test/temp/junit4-J1-20180228_030545_5987547545946888404169.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 162 lines...]
   [junit4] JVM J1: stderr was not empty, see: 

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_162) - Build # 21549 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21549/
Java: 32bit/jdk1.8.0_162 -client -XX:+UseG1GC

No tests ran.

Build Log:
[...truncated 58343 lines...]
[repro] Jenkins log URL: 
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21549/consoleText

[repro] Revision: 7dba350c7a02fe603faec49227ff2672e4d8e6ae

[repro] Ant options: "-Dargs=-client -XX:+UseG1GC"
[repro] No "reproduce with" lines found; exiting.

[...truncated 8 lines...]
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

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

[Apache Jenkins Server]

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

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

[repro] Revision: d512cd7604741a2f55deb0c840188f0342f1ba57

[repro] Ant options: -Dtests.badapples=false
[repro] Repro line:  ant test  -Dtestcase=ComputePlanActionTest 
-Dtests.method=testNodeLost -Dtests.seed=7875A4D5F78D85A3 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=en-SG -Dtests.timezone=Asia/Ho_Chi_Minh 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=TestInPlaceUpdatesDistrib 
-Dtests.method=test -Dtests.seed=7875A4D5F78D85A3 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=hr-HR -Dtests.timezone=America/Guatemala 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=TestInPlaceUpdatesDistrib 
-Dtests.seed=7875A4D5F78D85A3 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=hr-HR -Dtests.timezone=America/Guatemala -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=ChaosMonkeySafeLeaderTest 
-Dtests.method=test -Dtests.seed=7875A4D5F78D85A3 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=uk-UA -Dtests.timezone=America/Caracas 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=CloudSolrClientTest 
-Dtests.method=testRetryUpdatesWhenClusterStateIsStale 
-Dtests.seed=2D8A11C6DA4E350E -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=da -Dtests.timezone=America/St_Kitts -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=GraphTest 
-Dtests.seed=2D8A11C6DA4E350E -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=it-IT -Dtests.timezone=Europe/Tallinn -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
7dba350c7a02fe603faec49227ff2672e4d8e6ae
[repro] git fetch
[repro] git checkout d512cd7604741a2f55deb0c840188f0342f1ba57

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

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

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/solrj
[repro]   GraphTest
[repro]   CloudSolrClientTest
[repro]solr/core
[repro]   TestInPlaceUpdatesDistrib
[repro]   ChaosMonkeySafeLeaderTest
[repro]   ComputePlanActionTest
[repro] ant compile-test

[...truncated 2444 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.GraphTest|*.CloudSolrClientTest" -Dtests.showOutput=onerror 
-Dtests.badapples=false -Dtests.seed=2D8A11C6DA4E350E -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=it-IT -Dtests.timezone=Europe/Tallinn 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[...truncated 160 lines...]
[repro] ant compile-test

[...truncated 1329 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.TestInPlaceUpdatesDistrib|*.ChaosMonkeySafeLeaderTest|*.ComputePlanActionTest"
 -Dtests.showOutput=onerror -Dtests.badapples=false 
-Dtests.seed=7875A4D5F78D85A3 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=hr-HR -Dtests.timezone=America/Guatemala -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.client.solrj.impl.CloudSolrClientTest
[repro]   0/5 failed: org.apache.solr.client.solrj.io.graph.GraphTest
[repro]   0/5 failed: org.apache.solr.cloud.autoscaling.ComputePlanActionTest
[repro]   0/5 failed: org.apache.solr.update.TestInPlaceUpdatesDistrib
[repro]   3/5 failed: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest
[repro] git checkout 7dba350c7a02fe603faec49227ff2672e4d8e6ae

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

[...truncated 6 lines...]

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-9) - Build # 4466 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4466/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

No tests ran.

Build Log:
[...truncated 1845 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/core/test/temp/junit4-J1-20180228_011914_4751234163017188771291.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/core/test/temp/junit4-J0-20180228_011914_47516350782809749329079.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 287 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/test-framework/test/temp/junit4-J1-20180228_012653_6125360011717876895456.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/test-framework/test/temp/junit4-J0-20180228_012653_61212691260156936223712.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 1062 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/common/test/temp/junit4-J0-20180228_012807_13711019864935483005060.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/common/test/temp/junit4-J1-20180228_012807_1379129651140171708425.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 236 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/icu/test/temp/junit4-J1-20180228_013045_2405590632774829656159.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/icu/test/temp/junit4-J0-20180228_013045_2402085948933644125234.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 253 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/kuromoji/test/temp/junit4-J0-20180228_013100_8332788434415611319592.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/kuromoji/test/temp/junit4-J1-20180228_013100_8336073845118399595154.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 162 lines...]
   [junit4] JVM 

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_162) - Build # 1443 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1443/
Java: 64bit/jdk1.8.0_162 -XX:-UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove

Error Message:
No live SolrServers available to handle this 
request:[https://127.0.0.1:40151/solr/MoveReplicaHDFSTest_failed_coll_true, 
https://127.0.0.1:38143/solr/MoveReplicaHDFSTest_failed_coll_true]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[https://127.0.0.1:40151/solr/MoveReplicaHDFSTest_failed_coll_true, 
https://127.0.0.1:38143/solr/MoveReplicaHDFSTest_failed_coll_true]
at 
__randomizedtesting.SeedInfo.seed([DF5EA4A93431CF31:7593775B83E21AE1]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:462)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:991)
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.query(SolrClient.java:942)
at 
org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:307)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.1) - Build # 479 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/479/
Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseParallelGC

5 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_886BAA3BE6647C20-001\testPostingsEnumReuse-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_886BAA3BE6647C20-001\testPostingsEnumReuse-001

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_886BAA3BE6647C20-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_886BAA3BE6647C20-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_886BAA3BE6647C20-001\testPostingsEnumReuse-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_886BAA3BE6647C20-001\testPostingsEnumReuse-001
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_886BAA3BE6647C20-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_886BAA3BE6647C20-001

at __randomizedtesting.SeedInfo.seed([886BAA3BE6647C20]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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)


FAILED:  org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\replicator\test\J0\temp\lucene.replicator.http.HttpReplicatorTest_2060747AD3E7EBAD-001\httpReplicatorTest-001\1\index:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\replicator\test\J0\temp\lucene.replicator.http.HttpReplicatorTest_2060747AD3E7EBAD-001\httpReplicatorTest-001\1\index

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\replicator\test\J0\temp\lucene.replicator.http.HttpReplicatorTest_2060747AD3E7EBAD-001\httpReplicatorTest-001\1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\replicator\test\J0\temp\lucene.replicator.http.HttpReplicatorTest_2060747AD3E7EBAD-001\httpReplicatorTest-001\1
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\replicator\test\J0\temp\lucene.replicator.http.HttpReplicatorTest_2060747AD3E7EBAD-001\httpReplicatorTest-001\1\index:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\replicator\test\J0\temp\lucene.replicator.http.HttpReplicatorTest_2060747AD3E7EBAD-001\httpReplicatorTest-001\1\index
   

[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 160 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 28782 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 491 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] Java 9 JAVA_HOME=/home/jenkins/tools/java/latest1.9
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (29.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.3.0-src.tgz...
   [smoker] 31.7 MB in 0.03 sec (1133.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.3.0.tgz...
   [smoker] 73.2 MB in 0.06 sec (1144.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.3.0.zip...
   [smoker] 83.8 MB in 0.07 sec (1143.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.3.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6290 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6290 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.3.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6290 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6290 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.3.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.badapples=false 
-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 217 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 9 and testArgs='-Dtests.badapples=false 
-Dtests.slow=false'...
   [smoker] test demo with 9...
   [smoker]   got 217 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.02 sec (12.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.3.0-src.tgz...
   [smoker] 54.1 MB in 0.46 sec (117.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.3.0.tgz...
   [smoker] 151.0 MB in 1.46 sec (103.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.3.0.zip...
   [smoker] 152.0 MB in 1.63 sec (93.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.3.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.3.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.3.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.3.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.3.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.3.0-java8
   [smoker] 

[jira] [Resolved] (SOLR-8173) CLONE - Leader recovery process can select the wrong leader if all replicas for a shard are down and trying to recover as well as lose updates that should have been recov

[Varun Thacker (JIRA)]

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

Varun Thacker resolved SOLR-8173.
-
Resolution: Duplicate

> CLONE - Leader recovery process can select the wrong leader if all replicas 
> for a shard are down and trying to recover as well as lose updates that 
> should have been recovered.
> ---
>
> Key: SOLR-8173
> URL: https://issues.apache.org/jira/browse/SOLR-8173
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Matteo Grolla
>Assignee: Mark Miller
>Priority: Critical
>  Labels: leader, recovery
> Attachments: solr_8983.log, solr_8984.log
>
>
> I'm doing this test
> collection test is replicated on two solr nodes running on 8983, 8984
> using external zk
> initially both nodes are empty
> 1)turn on solr 8983
> 2)add,commit a doc x con solr 8983
> 3)turn off solr 8983
> 4)turn on solr 8984
> 5)shortly after (leader still not elected) turn on solr 8983
> 6)8984 is elected as leader
> 7)doc x is present on 8983 but not on 8984 (check issuing a query)
> In attachment are the solr.log files of both instances



--
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-12028) BadApple and AwaitsFix annotations usage

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-12028:
--

Last run had following test failures, although {{tests,badapples=false}}: 
- 
org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testNodeMarkersRegistration
- org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testSearchRate
- org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, 
> SOLR-12028-sysprops-reproduce.patch, SOLR-12028.patch, SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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_162) - Build # 21548 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21548/
Java: 32bit/jdk1.8.0_162 -server -XX:+UseConcMarkSweepGC

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

Error Message:
Error uploading file 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/configsets/cloud-hdfs/conf/solrconfig.xml
 to zookeeper path /configs/conf/solrconfig.xml

Stack Trace:
java.io.IOException: Error uploading file 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/configsets/cloud-hdfs/conf/solrconfig.xml
 to zookeeper path /configs/conf/solrconfig.xml
at __randomizedtesting.SeedInfo.seed([C139D0262296DF9F]:0)
at 
org.apache.solr.common.cloud.ZkMaintenanceUtils$1.visitFile(ZkMaintenanceUtils.java:309)
at 
org.apache.solr.common.cloud.ZkMaintenanceUtils$1.visitFile(ZkMaintenanceUtils.java:291)
at java.nio.file.Files.walkFileTree(Files.java:2670)
at java.nio.file.Files.walkFileTree(Files.java:2742)
at 
org.apache.solr.common.cloud.ZkMaintenanceUtils.uploadToZK(ZkMaintenanceUtils.java:291)
at 
org.apache.solr.common.cloud.SolrZkClient.uploadToZK(SolrZkClient.java:793)
at 
org.apache.solr.common.cloud.ZkConfigManager.uploadConfigDir(ZkConfigManager.java:65)
at 
org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest.setupClass(HdfsRecoveryZkTest.java:45)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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)
Caused by: org.apache.zookeeper.KeeperException$SessionExpiredException: 
KeeperErrorCode = Session expired for /configs
at org.apache.zookeeper.KeeperException.create(KeeperException.java:130)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)
at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1105)
at 
org.apache.solr.common.cloud.SolrZkClient.lambda$exists$2(SolrZkClient.java:304)
at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
at 
org.apache.solr.common.cloud.SolrZkClient.exists(SolrZkClient.java:304)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:483)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:391)
at 
org.apache.solr.common.cloud.ZkMaintenanceUtils$1.visitFile(ZkMaintenanceUtils.java:305)
... 31 more


FAILED:  
org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testNodeMarkersRegistration

Error Message:
Path /autoscaling/nodeAdded/127.0.0.1:36773_solr wasn't created

Stack 

[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12028:


Commit 9b7e35e69b694d9006c0964ae7a26ed2694ea055 in lucene-solr's branch 
refs/heads/branch_7x from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9b7e35e ]

SOLR-12028: Make initialization of constants dynamic (by reading the 
annotation), also add missing reproduce info


> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, 
> SOLR-12028-sysprops-reproduce.patch, SOLR-12028.patch, SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-12028) BadApple and AwaitsFix annotations usage

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12028:


Commit 7dba350c7a02fe603faec49227ff2672e4d8e6ae in lucene-solr's branch 
refs/heads/master from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7dba350 ]

SOLR-12028: Make initialization of constants dynamic (by reading the 
annotation), also add missing reproduce info


> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, 
> SOLR-12028-sysprops-reproduce.patch, SOLR-12028.patch, SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-12028) BadApple and AwaitsFix annotations usage

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-12028:
--

Hi, I just noticed that the reproduce line was not consistent with all test 
groups. Also the sysprop defaults were initialized differently to the undelying 
annotations. This patch fixes this and makes the defaults "dynamic" (from 
annotation): [^SOLR-12028-sysprops-reproduce.patch]

Will commit in a moment.

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, 
> SOLR-12028-sysprops-reproduce.patch, SOLR-12028.patch, SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-12028) BadApple and AwaitsFix annotations usage

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-12028:
-
Attachment: SOLR-12028-sysprops-reproduce.patch

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, 
> SOLR-12028-sysprops-reproduce.patch, SOLR-12028.patch, SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-12031) Refactor Policy framework to let state changes to be applied to all nodes

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12031:
-
Component/s: AutoScaling

> Refactor Policy framework to let state changes to be applied to all nodes
> -
>
> Key: SOLR-12031
> URL: https://issues.apache.org/jira/browse/SOLR-12031
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-12031.patch
>
>
> The framework assumes that all variables will change the values in the same 
> node only. that doesn't have to be the case.
>  
> for instance  , when a replica for a given shard is a added to a node, it 
> actually increases the search rate in that node and decrease the search rate 
> on other nodes that host the same shard.
>  



--
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-12005) Solr should have the option of logging all jars loaded

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12005:
-
Component/s: logging

> Solr should have the option of logging all jars loaded
> --
>
> Key: SOLR-12005
> URL: https://issues.apache.org/jira/browse/SOLR-12005
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Reporter: Shawn Heisey
>Priority: Major
>
> Solr used to explicitly log the filename of every jar it loaded.  It seems 
> that the effort to reduce the verbosity of the logs has changed this, now it 
> just logs the *count* of jars loaded and the paths where they were loaded 
> from.  Here's a log line where Solr is reading from ${solr.solr.home}/lib:
> {code}
> 2018-02-01 17:43:20.043 INFO  (main) [   ] o.a.s.c.SolrResourceLoader [null] 
> Added 8 libs to classloader, from paths: [/index/solr6/data/lib]
> {code}
> When trying to help somebody with classloader issues, it's more difficult to 
> help when the list of jars loaded isn't in the log.
> I would like the more verbose logging to be enabled by default, but I 
> understand that many people would not want that, so I propose this:
>  * Enable verbose logging for ${solr.solr.home}/lib by default.
>  * Disable verbose logging for each core by default.  Allow solrconfig.xml to 
> enable it.
>  * Optionally allow solr.xml to configure verbose logging at the global level.
>  ** This setting would affect both global and per-core jar loading. Each 
> solrconfig.xml could override.
> Rationale: The contents of ${solr.solr.home}/lib are loaded precisely once, 
> and this location doesn't even exist unless a user creates it.  An 
> out-of-the-box config would not have verbose logs from jar loading.
> The solr home lib location is my preferred way of loading custom jars, 
> because they get loaded only once, no matter how many cores you have.  Jars 
> added to this location would add lines to the log, but it would not be logged 
> for every core.



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

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

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_144) - Build # 7196 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7196/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseParallelGC

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.lucene.store.TestMultiMMap

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_1DB91FC62943F0F4-001\testSeekSliceZero-006:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_1DB91FC62943F0F4-001\testSeekSliceZero-006
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_1DB91FC62943F0F4-001\testSeekSliceZero-006:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_1DB91FC62943F0F4-001\testSeekSliceZero-006

at __randomizedtesting.SeedInfo.seed([1DB91FC62943F0F4]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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:  
junit.framework.TestSuite.org.apache.solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_10BAE5C2625B3390-001\tempDir-001\collection1\conf:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_10BAE5C2625B3390-001\tempDir-001\collection1\conf

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_10BAE5C2625B3390-001\tempDir-001\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_10BAE5C2625B3390-001\tempDir-001\collection1

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_10BAE5C2625B3390-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_10BAE5C2625B3390-001\tempDir-001

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_10BAE5C2625B3390-001\tempDir-001\collection1\conf\en-test-tokenizer.bin:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_10BAE5C2625B3390-001\tempDir-001\collection1\conf\en-test-tokenizer.bin

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_10BAE5C2625B3390-001\tempDir-001\collection1\conf\en-test-sent.bin:
 java.nio.file.AccessDeniedException: 

[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-12028:
--

Good idea with the extra target.

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-12041) NPE in ChaosMonkeyNothingIsSafeWithPullReplicasTest

[JIRA]

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

Tomás Fernández Löbbe resolved SOLR-12041.
--
Resolution: Fixed

> NPE in ChaosMonkeyNothingIsSafeWithPullReplicasTest
> ---
>
> Key: SOLR-12041
> URL: https://issues.apache.org/jira/browse/SOLR-12041
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-12041.patch, SOLR-12041.patch
>
>
> I found this failure in Steve’s Jenkins 
> (http://fucit.org/solr-jenkins-reports/job-data/sarowe/Lucene-Solr-tests-7.x/2910/):
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=ChaosMonkeyNothingIsSafeWithPullReplicasTest -Dtests.method=test 
> -Dtests.seed=FEC5BFCB68EE30B1 -Dtests.slow=true -Dtests.locale=he-IL 
> -Dtests.timezone=Pacific/Midway -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   37.8s J8  | 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest.test <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([FEC5BFCB68EE30B1:76918011C6125D49]:0)
>[junit4]>at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.getIndexVersion(AbstractFullDistribZkTestBase.java:2172)
>[junit4]>at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForReplicationFromReplicas(AbstractFullDistribZkTestBase.java:2110)
>[junit4]>at 
> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test(ChaosMonkeyNothingIsSafeWithPullReplicasTest.java:268)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It seems to be caused by this code:
> {code:java}
> for(Slice s:collection.getSlices()) {
>   Replica leader = s.getLeader();
>   long leaderIndexVersion = -1;
>   while (!timeout.hasTimedOut()) {
> —> leaderIndexVersion = getIndexVersion(leader);
> {code}
> and I believe the problem is that the shard may not have a leader at the time 
> of this check.



--
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-12041) NPE in ChaosMonkeyNothingIsSafeWithPullReplicasTest

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12041:


Commit 029432e9360b9e90610332e83b136e2334c0517f in lucene-solr's branch 
refs/heads/master from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=029432e ]

SOLR-12041: Fix random test failure in 
ChaosMonkeyNothingIsSafeWithPullReplicasTest


> NPE in ChaosMonkeyNothingIsSafeWithPullReplicasTest
> ---
>
> Key: SOLR-12041
> URL: https://issues.apache.org/jira/browse/SOLR-12041
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-12041.patch, SOLR-12041.patch
>
>
> I found this failure in Steve’s Jenkins 
> (http://fucit.org/solr-jenkins-reports/job-data/sarowe/Lucene-Solr-tests-7.x/2910/):
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=ChaosMonkeyNothingIsSafeWithPullReplicasTest -Dtests.method=test 
> -Dtests.seed=FEC5BFCB68EE30B1 -Dtests.slow=true -Dtests.locale=he-IL 
> -Dtests.timezone=Pacific/Midway -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   37.8s J8  | 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest.test <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([FEC5BFCB68EE30B1:76918011C6125D49]:0)
>[junit4]>at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.getIndexVersion(AbstractFullDistribZkTestBase.java:2172)
>[junit4]>at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForReplicationFromReplicas(AbstractFullDistribZkTestBase.java:2110)
>[junit4]>at 
> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test(ChaosMonkeyNothingIsSafeWithPullReplicasTest.java:268)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It seems to be caused by this code:
> {code:java}
> for(Slice s:collection.getSlices()) {
>   Replica leader = s.getLeader();
>   long leaderIndexVersion = -1;
>   while (!timeout.hasTimedOut()) {
> —> leaderIndexVersion = getIndexVersion(leader);
> {code}
> and I believe the problem is that the shard may not have a leader at the time 
> of this check.



--
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-12041) NPE in ChaosMonkeyNothingIsSafeWithPullReplicasTest

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12041:


Commit 4ccf500800ee497fceb93f4727a89a8a4533bb10 in lucene-solr's branch 
refs/heads/branch_7x from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4ccf500 ]

SOLR-12041: Fix random test failure in 
ChaosMonkeyNothingIsSafeWithPullReplicasTest


> NPE in ChaosMonkeyNothingIsSafeWithPullReplicasTest
> ---
>
> Key: SOLR-12041
> URL: https://issues.apache.org/jira/browse/SOLR-12041
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-12041.patch, SOLR-12041.patch
>
>
> I found this failure in Steve’s Jenkins 
> (http://fucit.org/solr-jenkins-reports/job-data/sarowe/Lucene-Solr-tests-7.x/2910/):
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=ChaosMonkeyNothingIsSafeWithPullReplicasTest -Dtests.method=test 
> -Dtests.seed=FEC5BFCB68EE30B1 -Dtests.slow=true -Dtests.locale=he-IL 
> -Dtests.timezone=Pacific/Midway -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   37.8s J8  | 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest.test <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([FEC5BFCB68EE30B1:76918011C6125D49]:0)
>[junit4]>at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.getIndexVersion(AbstractFullDistribZkTestBase.java:2172)
>[junit4]>at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForReplicationFromReplicas(AbstractFullDistribZkTestBase.java:2110)
>[junit4]>at 
> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test(ChaosMonkeyNothingIsSafeWithPullReplicasTest.java:268)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It seems to be caused by this code:
> {code:java}
> for(Slice s:collection.getSlices()) {
>   Replica leader = s.getLeader();
>   long leaderIndexVersion = -1;
>   while (!timeout.hasTimedOut()) {
> —> leaderIndexVersion = getIndexVersion(leader);
> {code}
> and I believe the problem is that the shard may not have a leader at the time 
> of this check.



--
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-12041) NPE in ChaosMonkeyNothingIsSafeWithPullReplicasTest

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-12041:
--

Running tests with the patch I noticed that there are lots of ZkConnection 
errors and thread leaks after the test is done. I see this is happening in 
master without my change, but it wasn't like this before... I'll open another 
Jira for that

> NPE in ChaosMonkeyNothingIsSafeWithPullReplicasTest
> ---
>
> Key: SOLR-12041
> URL: https://issues.apache.org/jira/browse/SOLR-12041
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-12041.patch, SOLR-12041.patch
>
>
> I found this failure in Steve’s Jenkins 
> (http://fucit.org/solr-jenkins-reports/job-data/sarowe/Lucene-Solr-tests-7.x/2910/):
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=ChaosMonkeyNothingIsSafeWithPullReplicasTest -Dtests.method=test 
> -Dtests.seed=FEC5BFCB68EE30B1 -Dtests.slow=true -Dtests.locale=he-IL 
> -Dtests.timezone=Pacific/Midway -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   37.8s J8  | 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest.test <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([FEC5BFCB68EE30B1:76918011C6125D49]:0)
>[junit4]>at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.getIndexVersion(AbstractFullDistribZkTestBase.java:2172)
>[junit4]>at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForReplicationFromReplicas(AbstractFullDistribZkTestBase.java:2110)
>[junit4]>at 
> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test(ChaosMonkeyNothingIsSafeWithPullReplicasTest.java:268)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It seems to be caused by this code:
> {code:java}
> for(Slice s:collection.getSlices()) {
>   Replica leader = s.getLeader();
>   long leaderIndexVersion = -1;
>   while (!timeout.hasTimedOut()) {
> —> leaderIndexVersion = getIndexVersion(leader);
> {code}
> and I believe the problem is that the shard may not have a leader at the time 
> of this check.



--
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-12041) NPE in ChaosMonkeyNothingIsSafeWithPullReplicasTest

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-12041:
-
Attachment: SOLR-12041.patch

> NPE in ChaosMonkeyNothingIsSafeWithPullReplicasTest
> ---
>
> Key: SOLR-12041
> URL: https://issues.apache.org/jira/browse/SOLR-12041
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-12041.patch, SOLR-12041.patch
>
>
> I found this failure in Steve’s Jenkins 
> (http://fucit.org/solr-jenkins-reports/job-data/sarowe/Lucene-Solr-tests-7.x/2910/):
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=ChaosMonkeyNothingIsSafeWithPullReplicasTest -Dtests.method=test 
> -Dtests.seed=FEC5BFCB68EE30B1 -Dtests.slow=true -Dtests.locale=he-IL 
> -Dtests.timezone=Pacific/Midway -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   37.8s J8  | 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest.test <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([FEC5BFCB68EE30B1:76918011C6125D49]:0)
>[junit4]>at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.getIndexVersion(AbstractFullDistribZkTestBase.java:2172)
>[junit4]>at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForReplicationFromReplicas(AbstractFullDistribZkTestBase.java:2110)
>[junit4]>at 
> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test(ChaosMonkeyNothingIsSafeWithPullReplicasTest.java:268)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It seems to be caused by this code:
> {code:java}
> for(Slice s:collection.getSlices()) {
>   Replica leader = s.getLeader();
>   long leaderIndexVersion = -1;
>   while (!timeout.hasTimedOut()) {
> —> leaderIndexVersion = getIndexVersion(leader);
> {code}
> and I believe the problem is that the shard may not have a leader at the time 
> of this check.



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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 2387 - Still Unstable

[Apache Jenkins Server]

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

7 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test

Error Message:
shard2 is not consistent.  Got 25 from 
http://127.0.0.1:33742/u_/d/collection1_shard2_replica_n41 (previous client) 
and got 26 from http://127.0.0.1:38643/u_/d/collection1_shard2_replica_n45

Stack Trace:
java.lang.AssertionError: shard2 is not consistent.  Got 25 from 
http://127.0.0.1:33742/u_/d/collection1_shard2_replica_n41 (previous client) 
and got 26 from http://127.0.0.1:38643/u_/d/collection1_shard2_replica_n45
at 
__randomizedtesting.SeedInfo.seed([7875A4D5F78D85A3:F0219B0F5971E85B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1330)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1309)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:162)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

Re: Test failures are out of control......

[Karl Wright]

It succeeds but it takes too long, so I committed a reduction in the number
of iterations that are attempted for nightly from 20 to 5.  That
should make it pass reliably.

Karl


On Tue, Feb 27, 2018 at 3:52 PM, Erick Erickson 
wrote:

> Karl:
>
> Let us know if you can't get this to fail locally, we can turn it back
> on on Jenkins as long as it's getting active attention.
>
> Erick
>
> On Tue, Feb 27, 2018 at 12:40 PM, Karl Wright  wrote:
> > I looked at the Geo3d failures; these are timeouts exclusively.  I
> suspect
> > we're seeing a test issue.  Will try to correct.
> >
> > Karl
> >
> >
> > On Tue, Feb 27, 2018 at 1:51 PM, Chris Hostetter <
> hossman_luc...@fucit.org>
> > wrote:
> >>
> >> : The most interesting bit is probably here...
> >> :
> >> :   http://fucit.org/solr-jenkins-reports/failure-report.html
> >>
> >> FYI:
> >>
> >> I realized this morning that the "Suite Runs" counts were being
> >> artificially inflated for suites that are frequently SKIPPED (either
> >> because they are @Nighly or @Slow and not run by all jenkins jobs).
> I've
> >> now fixed this, so at a glance the "suite level" failure rates are
> >> much higher today then they have been if you looked at it in the past.
> >>
> >> It means it's also now possible for a Suite failure rate to be greater
> >> then 100%, because sometimes it's reporting multiple suite level
> failures
> >> for a single run.
> >>
> >>
> >> Other follow up on some previous comments...
> >>
> >> : 1) there's some noise inthe '7days' data because I wasn't accounting
> for
> >> : the way jenkins reports some types of failure -- that will gradually
> >> clean
> >> : itself up
> >>
> >> ...some of these "Class: xml" failures are still visible in the report
> but
> >> should drop off over the next few days
> >>
> >> : 2) I think i've been been blocked by builds.apache.org, so at the
> moment
> >> : the data seems to just be from the sarowe & policeman jenkins
> failures.
> >>
> >> ...this is fixed.
> >>
> >> : 3) allthough the system is archiving the past 7 days worth of jenkins
> >> logs
> >> : for any jobs with failures, there is currently no easy way to download
> >> : the relevant log(s) from that failure report -- you currently have to
> >>
> >> ...this is also fixed.  now if you click on any row in the test you'll
> get
> >> a pop up showing you a link to all the job-data dirs that recorded a
> >> failure on that report view.  The most recent jobs are listed first.
> >>
> >>
> >>
> >> -Hoss
> >> http://www.lucidworks.com/
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Resolved] (LUCENE-8187) Spatial3d test times out 1/3 of the time

[Karl Wright (JIRA)]

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

Karl Wright resolved LUCENE-8187.
-
   Resolution: Fixed
Fix Version/s: 7.3
   master (8.0)
   6.7

> Spatial3d test times out 1/3 of the time
> 
>
> Key: LUCENE-8187
> URL: https://issues.apache.org/jira/browse/LUCENE-8187
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, master (8.0), 7.3
>
>
> Reproduce with:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testRandomBig 
> -Dtests.seed=CD4A0C5760E678E6 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.locale=is -Dtests.timezone=America/Martinique 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> {code}



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

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

[jira] [Commented] (LUCENE-8187) Spatial3d test times out 1/3 of the time

[ASF subversion and git services (JIRA)]

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

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

Commit cb4b6a1b7eec20c819df9c4606b7b28dcbdd0096 in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cb4b6a1 ]

LUCENE-8187: Reduce the count of test iterations for nightly because it was 
causing timeouts.


> Spatial3d test times out 1/3 of the time
> 
>
> Key: LUCENE-8187
> URL: https://issues.apache.org/jira/browse/LUCENE-8187
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
>
> Reproduce with:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testRandomBig 
> -Dtests.seed=CD4A0C5760E678E6 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.locale=is -Dtests.timezone=America/Martinique 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> {code}



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

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

[jira] [Commented] (LUCENE-8187) Spatial3d test times out 1/3 of the time

[ASF subversion and git services (JIRA)]

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

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

Commit d21e104de2d88147769b976d88c64a254145999e in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d21e104 ]

LUCENE-8187: Reduce the count of test iterations for nightly because it was 
causing timeouts.


> Spatial3d test times out 1/3 of the time
> 
>
> Key: LUCENE-8187
> URL: https://issues.apache.org/jira/browse/LUCENE-8187
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
>
> Reproduce with:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testRandomBig 
> -Dtests.seed=CD4A0C5760E678E6 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.locale=is -Dtests.timezone=America/Martinique 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> {code}



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

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

[jira] [Commented] (LUCENE-8187) Spatial3d test times out 1/3 of the time

[ASF subversion and git services (JIRA)]

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

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

Commit 9b0127f8cd180db3a50a9a125a79ada8daa1378e in lucene-solr's branch 
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9b0127f ]

LUCENE-8187: Reduce the count of test iterations for nightly because it was 
causing timeouts.


> Spatial3d test times out 1/3 of the time
> 
>
> Key: LUCENE-8187
> URL: https://issues.apache.org/jira/browse/LUCENE-8187
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
>
> Reproduce with:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testRandomBig 
> -Dtests.seed=CD4A0C5760E678E6 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.locale=is -Dtests.timezone=America/Martinique 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> {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-repro - Build # 157 - Still Unstable

[Apache Jenkins Server]

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

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

[repro] Revision: d512cd7604741a2f55deb0c840188f0342f1ba57

[repro] Repro line:  ant test  -Dtestcase=TestAuthenticationFramework 
-Dtests.method=testBasics -Dtests.seed=B199F550DA2D3A63 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=zh-HK -Dtests.timezone=GMT 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=ZkControllerTest 
-Dtests.method=testPublishAndWaitForDownStates -Dtests.seed=B199F550DA2D3A63 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=fr-FR 
-Dtests.timezone=Portugal -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestReplicationHandler 
-Dtests.method=doTestIndexFetchOnMasterRestart -Dtests.seed=B199F550DA2D3A63 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=sr-Latn-BA 
-Dtests.timezone=America/Indianapolis -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestJmxIntegration 
-Dtests.method=testJmxOnCoreReload -Dtests.seed=B199F550DA2D3A63 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=fr-CH 
-Dtests.timezone=Asia/Baku -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=SSLMigrationTest 
-Dtests.seed=B199F550DA2D3A63 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=ar -Dtests.timezone=Asia/Taipei -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestUtilizeNode -Dtests.method=test 
-Dtests.seed=B199F550DA2D3A63 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=nl-NL -Dtests.timezone=America/Monterrey -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=AtomicUpdateProcessorFactoryTest 
-Dtests.method=testMultipleThreads -Dtests.seed=B199F550DA2D3A63 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=pt-PT 
-Dtests.timezone=Europe/Belgrade -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestLTRReRankingPipeline 
-Dtests.method=testDifferentTopN -Dtests.seed=B4FF1E3DB83E88C7 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=uk-UA 
-Dtests.timezone=Asia/Dili -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: 
7de694e7713ef59ac6b578c0f8ee10759dd6a30e
[repro] git fetch
[repro] git checkout d512cd7604741a2f55deb0c840188f0342f1ba57

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

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

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/contrib/ltr
[repro]   TestLTRReRankingPipeline
[repro]solr/core
[repro]   TestReplicationHandler
[repro]   AtomicUpdateProcessorFactoryTest
[repro]   SSLMigrationTest
[repro]   ZkControllerTest
[repro]   TestUtilizeNode
[repro]   TestAuthenticationFramework
[repro]   TestJmxIntegration
[repro] ant compile-test

[...truncated 2563 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestLTRReRankingPipeline" -Dtests.showOutput=onerror  
-Dtests.seed=B4FF1E3DB83E88C7 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=uk-UA -Dtests.timezone=Asia/Dili -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

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

[repro] ant compile-test

[...truncated 1329 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=35 
-Dtests.class="*.TestReplicationHandler|*.AtomicUpdateProcessorFactoryTest|*.SSLMigrationTest|*.ZkControllerTest|*.TestUtilizeNode|*.TestAuthenticationFramework|*.TestJmxIntegration"
 -Dtests.showOutput=onerror  -Dtests.seed=B199F550DA2D3A63 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=sr-Latn-BA 
-Dtests.timezone=America/Indianapolis -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

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

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.TestAuthenticationFramework
[repro]   1/5 failed: org.apache.solr.cloud.TestUtilizeNode
[repro]   1/5 failed: 
org.apache.solr.update.processor.AtomicUpdateProcessorFactoryTest
[repro]   5/5 failed: org.apache.solr.cloud.SSLMigrationTest
[repro]   5/5 failed: org.apache.solr.cloud.ZkControllerTest
[repro]   5/5 failed: org.apache.solr.core.TestJmxIntegration
[repro]   5/5 failed: org.apache.solr.handler.TestReplicationHandler
[repro]   5/5 failed: org.apache.solr.ltr.TestLTRReRankingPipeline

[repro] Re-testing 100% failures at the tip of master
[repro] ant clean

[...truncated 8 lines...]
[repro] Test suites by module:
[repro]solr/contrib/ltr
[repro]   TestLTRReRankingPipeline
[repro]solr/core
[repro]   TestReplicationHandler
[repro]   SSLMigrationTest

[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12028:


Commit 7f72a4a5262aaf9276d8f3b17c56ac35abe6d48f in lucene-solr's branch 
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7f72a4a ]

SOLR-12028: add jenkins-nightly-badapples target


> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-12028) BadApple and AwaitsFix annotations usage

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12028:


Commit 939aedfed7a66065e2dfa42efb6fd4b53f9fab12 in lucene-solr's branch 
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=939aedf ]

SOLR-12028: add jenkins-nightly-badapples target


> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-8187) Spatial3d test times out 1/3 of the time

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8187:
-

It runs for 41 minutes on the bad case above but doesn't fail.  Too many 
iterations; we shouldn't try for so much in one nightly run.


> Spatial3d test times out 1/3 of the time
> 
>
> Key: LUCENE-8187
> URL: https://issues.apache.org/jira/browse/LUCENE-8187
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
>
> Reproduce with:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testRandomBig 
> -Dtests.seed=CD4A0C5760E678E6 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.locale=is -Dtests.timezone=America/Martinique 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> {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] (LUCENE-8187) Spatial3d test times out 1/3 of the time

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-8187:

Attachment: (was: image-2018-02-27-15-42-14-460.png)

> Spatial3d test times out 1/3 of the time
> 
>
> Key: LUCENE-8187
> URL: https://issues.apache.org/jira/browse/LUCENE-8187
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
>
> Reproduce with:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testRandomBig 
> -Dtests.seed=CD4A0C5760E678E6 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.locale=is -Dtests.timezone=America/Martinique 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> {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-11882) SolrMetric registries retain references to SolrCores when closed

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-11882:
--
Fix Version/s: (was: 7.3)

> SolrMetric registries retain references to SolrCores when closed
> 
>
> Key: SOLR-11882
> URL: https://issues.apache.org/jira/browse/SOLR-11882
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics, Server
>Affects Versions: 7.1
>Reporter: Eros Taborelli
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-11882.patch, SOLR-11882.patch, SOLR-11882.patch, 
> SOLR-11882.patch, create-cores.zip, solr-dump-full_Leak_Suspects.zip, 
> solr.config.zip
>
>
> *Description:*
> Our setup involves using a lot of small cores (possibly hundred thousand), 
> but working only on a few of them at any given time.
> We already followed all recommendations in this guide: 
> [https://wiki.apache.org/solr/LotsOfCores]
> We noticed that after creating/loading around 1000-2000 empty cores, with no 
> documents inside, the heap consumption went through the roof despite having 
> set transientCacheSize to only 64 (heap size set to 12G).
> All cores are correctly set to loadOnStartup=false and transient=true, and we 
> have verified via logs that the cores in excess are actually being closed.
> However, a reference remains in the 
> org.apache.solr.metrics.SolrMetricManager#registries that is never removed 
> until a core if fully unloaded.
> Restarting the JVM loads all cores in the admin UI, but doesn't populate the 
> ConcurrentHashMap until a core is actually fully loaded.
> I reproduced the issue on a smaller scale (transientCacheSize = 5, heap size 
> = 512m) and made a report (attached) using eclipse MAT.
> *Desired outcome:*
> When a transient core is closed, the references in the SolrMetricManager 
> should be removed, in the same fashion the reporters for the core are also 
> closed and removed.
> In alternative, a unloadOnClose=true|false flag could be implemented to fully 
> unload a transient core when closed due to the cache size.
> *Note:*
> The documentation mentions everywhere that the unused cores will be unloaded, 
> but it's misleading as the cores are never fully unloaded.



--
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-12028) BadApple and AwaitsFix annotations usage

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-12028:
---

Thanks [~thetaphi], I'll remove the useless property from ASF Jenkins jobs.

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-12028) BadApple and AwaitsFix annotations usage

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-12028:
--

Hi [~steve_rowe]: There was a typo in property name, the ANT tasks are setup 
correctly. I removed the useless property from jenkins, it should just run "ant 
jenkins-hourly" or "ant jenkins-badapples", nothing more.

I did not touch ASF Jenkins. I will setup daily jobs calling "ant 
jenkins-badapples" later!

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



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

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

[jira] [Comment Edited] (SOLR-12028) BadApple and AwaitsFix annotations usage

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-12028 at 2/27/18 9:41 PM:
---

Hi [~steve_rowe]: There was a typo in property name, the ANT tasks are setup 
correctly. I removed the useless property from jenkins, it should just run "ant 
jenkins-hourly" or "ant jenkins-badapples", nothing more.

I did not touch ASF Jenkins. I will setup daily jobs calling "ant 
jenkins-badapples" on policeman later!


was (Author: thetaphi):
Hi [~steve_rowe]: There was a typo in property name, the ANT tasks are setup 
correctly. I removed the useless property from jenkins, it should just run "ant 
jenkins-hourly" or "ant jenkins-badapples", nothing more.

I did not touch ASF Jenkins. I will setup daily jobs calling "ant 
jenkins-badapples" later!

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-12028) BadApple and AwaitsFix annotations usage

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12028:


Commit 73d5b070c911d03264a600521df06b2b07466304 in lucene-solr's branch 
refs/heads/branch_7x from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=73d5b07 ]

SOLR-12028: Fix typo in property name


> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-12028) BadApple and AwaitsFix annotations usage

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12028:


Commit 98d85eadd4ed0ebab3e4c37aff88749350934524 in lucene-solr's branch 
refs/heads/master from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=98d85ea ]

SOLR-12028: Fix typo in property name


> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-11067) REPLACENODE should make it optional to provide a target node

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11067:


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

SOLR-11067: AwaitsFix. The test fails often as the target node some times is 
same as the source node


> REPLACENODE should make it optional to provide a target node
> 
>
> Key: SOLR-11067
> URL: https://issues.apache.org/jira/browse/SOLR-11067
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11067.patch
>
>
> The REPLACENODE API currently accepts a replacement target and moves all 
> replicas from the source to the given target. We can improve this by having 
> it figure out the right target node for each replica contained in the source.
> This can also then be a thin wrapper over nodeLost event just like how 
> UTILIZENODE (SOLR-9743) can be a wrapper over nodeAdded event.



--
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-12042) Authorization rules do not work as expected.

[Nikolay Martynov (JIRA)]

Nikolay Martynov created SOLR-12042:
---

 Summary: Authorization rules do not work as expected.
 Key: SOLR-12042
 URL: https://issues.apache.org/jira/browse/SOLR-12042
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Authentication
Affects Versions: 6.6.2
 Environment: SolrCloud, Linux.
Reporter: Nikolay Martynov


Authentication rules do not work as expected: more permissions are given than 
desired.

This is an example of security.json:
{noformat}
{
 "authentication":{
   "blockUnknown":false,
   "class":"solr.BasicAuthPlugin",
   "credentials":{"admin":"XvyR9ddaDk/kVNBrhJHkeWhqTFQ2uAsv8tDOmkSDwkg= 
3EiRiSQVKYnGDgOwBoY6NJNlOcoRuYZOoUMYB9hgpGw="},
   "":{"v":56}},
 "authorization":{
   "class":"solr.RuleBasedAuthorizationPlugin",
   "user-role":{"admin":["admin"]},
   "":{"v":66},
   "permissions":[
 {
   "name":"read",
   "role":null,
   "index":1},
 {
   "path":"/admin/info/system",
   "collection":null,
   "role":null,
   "index":2},
 {
   "name":"all",
   "role":"admin",
   "index":3}]}}
{noformat}

With this not authentication is required to create or delete collection.
If one removes second rule (one with path) then authentication is required to 
create or destroy collection.



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

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

[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-12028:
--

Steve: see here: 
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blobdiff;f=build.xml;h=ceff8d2a36b6a30a52b517a8b32ed6e31153;hp=a5f09e48711447852e20cad1c6f98c270abd0193;hb=1fe4560;hpb=1fc3ca0cbb2fcdd99c4a58dcf98d346e1bab5015

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



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

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

[jira] [Comment Edited] (SOLR-12028) BadApple and AwaitsFix annotations usage

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-12028 at 2/27/18 9:22 PM:
---

[~steve_rowe], with this patch you don't need to change the existing jobs. If 
you run "ant jenkins-hourly" ant task it will not run bad apples. If you run 
"jenkins-badapples" it's the new variant. It's all in build file!


was (Author: thetaphi):
[~steve_rowe]Steve, with this patch you don't need to change the existing jobs. 
If you run "ant jenkins-hourly" ant task it will not run bad apples. If you run 
"jenkins-badapples" it's the new variant. It's all in build file!

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-12028) BadApple and AwaitsFix annotations usage

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-12028:
---

[~thetaphi] This is committed, I'm keeping it open for a bit while we adjust.


> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-12028) BadApple and AwaitsFix annotations usage

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-12028:
--

[~steve_rowe]Steve, with this patch you don't need to change the existing jobs. 
If you run "ant jenkins-hourly" ant task it will not run bad apples. If you run 
"jenkins-badapples" it's the new variant. It's all in build file!

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-12028) BadApple and AwaitsFix annotations usage

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-12028:
--

bq. Uwe Schindler, do you want to host badapple tests on Policeman Jenkins?

Yes, sure. I'd prefer {{@daily/2}}. When this is commit I will duplicate Master 
and 7.x Jobs. For release branches it makes no sense to run BadApple tests. But 
that's my opinion.

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-12041) NPE in ChaosMonkeyNothingIsSafeWithPullReplicasTest

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-12041:
-
Attachment: SOLR-12041.patch

> NPE in ChaosMonkeyNothingIsSafeWithPullReplicasTest
> ---
>
> Key: SOLR-12041
> URL: https://issues.apache.org/jira/browse/SOLR-12041
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-12041.patch
>
>
> I found this failure in Steve’s Jenkins 
> (http://fucit.org/solr-jenkins-reports/job-data/sarowe/Lucene-Solr-tests-7.x/2910/):
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=ChaosMonkeyNothingIsSafeWithPullReplicasTest -Dtests.method=test 
> -Dtests.seed=FEC5BFCB68EE30B1 -Dtests.slow=true -Dtests.locale=he-IL 
> -Dtests.timezone=Pacific/Midway -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   37.8s J8  | 
> ChaosMonkeyNothingIsSafeWithPullReplicasTest.test <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([FEC5BFCB68EE30B1:76918011C6125D49]:0)
>[junit4]>at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.getIndexVersion(AbstractFullDistribZkTestBase.java:2172)
>[junit4]>at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForReplicationFromReplicas(AbstractFullDistribZkTestBase.java:2110)
>[junit4]>at 
> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test(ChaosMonkeyNothingIsSafeWithPullReplicasTest.java:268)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
>[junit4]>at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It seems to be caused by this code:
> {code:java}
> for(Slice s:collection.getSlices()) {
>   Replica leader = s.getLeader();
>   long leaderIndexVersion = -1;
>   while (!timeout.hasTimedOut()) {
> —> leaderIndexVersion = getIndexVersion(leader);
> {code}
> and I believe the problem is that the shard may not have a leader at the time 
> of this check.



--
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-12041) NPE in ChaosMonkeyNothingIsSafeWithPullReplicasTest

[JIRA]

Tomás Fernández Löbbe created SOLR-12041:


 Summary: NPE in ChaosMonkeyNothingIsSafeWithPullReplicasTest
 Key: SOLR-12041
 URL: https://issues.apache.org/jira/browse/SOLR-12041
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Tests
Reporter: Tomás Fernández Löbbe
Assignee: Tomás Fernández Löbbe


I found this failure in Steve’s Jenkins 
(http://fucit.org/solr-jenkins-reports/job-data/sarowe/Lucene-Solr-tests-7.x/2910/):
{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=ChaosMonkeyNothingIsSafeWithPullReplicasTest -Dtests.method=test 
-Dtests.seed=FEC5BFCB68EE30B1 -Dtests.slow=true -Dtests.locale=he-IL 
-Dtests.timezone=Pacific/Midway -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] ERROR   37.8s J8  | 
ChaosMonkeyNothingIsSafeWithPullReplicasTest.test <<<
   [junit4]> Throwable #1: java.lang.NullPointerException
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([FEC5BFCB68EE30B1:76918011C6125D49]:0)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.getIndexVersion(AbstractFullDistribZkTestBase.java:2172)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForReplicationFromReplicas(AbstractFullDistribZkTestBase.java:2110)
   [junit4]>at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test(ChaosMonkeyNothingIsSafeWithPullReplicasTest.java:268)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
{noformat}

It seems to be caused by this code:
{code:java}
for(Slice s:collection.getSlices()) {
  Replica leader = s.getLeader();
  long leaderIndexVersion = -1;
  while (!timeout.hasTimedOut()) {
—> leaderIndexVersion = getIndexVersion(leader);
{code}
and I believe the problem is that the shard may not have a leader at the time 
of this check.




--
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: Test failures are out of control......

[Erick Erickson]

Karl:

Let us know if you can't get this to fail locally, we can turn it back
on on Jenkins as long as it's getting active attention.

Erick

On Tue, Feb 27, 2018 at 12:40 PM, Karl Wright  wrote:
> I looked at the Geo3d failures; these are timeouts exclusively.  I suspect
> we're seeing a test issue.  Will try to correct.
>
> Karl
>
>
> On Tue, Feb 27, 2018 at 1:51 PM, Chris Hostetter 
> wrote:
>>
>> : The most interesting bit is probably here...
>> :
>> :   http://fucit.org/solr-jenkins-reports/failure-report.html
>>
>> FYI:
>>
>> I realized this morning that the "Suite Runs" counts were being
>> artificially inflated for suites that are frequently SKIPPED (either
>> because they are @Nighly or @Slow and not run by all jenkins jobs).  I've
>> now fixed this, so at a glance the "suite level" failure rates are
>> much higher today then they have been if you looked at it in the past.
>>
>> It means it's also now possible for a Suite failure rate to be greater
>> then 100%, because sometimes it's reporting multiple suite level failures
>> for a single run.
>>
>>
>> Other follow up on some previous comments...
>>
>> : 1) there's some noise inthe '7days' data because I wasn't accounting for
>> : the way jenkins reports some types of failure -- that will gradually
>> clean
>> : itself up
>>
>> ...some of these "Class: xml" failures are still visible in the report but
>> should drop off over the next few days
>>
>> : 2) I think i've been been blocked by builds.apache.org, so at the moment
>> : the data seems to just be from the sarowe & policeman jenkins failures.
>>
>> ...this is fixed.
>>
>> : 3) allthough the system is archiving the past 7 days worth of jenkins
>> logs
>> : for any jobs with failures, there is currently no easy way to download
>> : the relevant log(s) from that failure report -- you currently have to
>>
>> ...this is also fixed.  now if you click on any row in the test you'll get
>> a pop up showing you a link to all the job-data dirs that recorded a
>> failure on that report view.  The most recent jobs are listed first.
>>
>>
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

[jira] [Created] (LUCENE-8187) Spatial3d test times out 1/3 of the time

[Karl Wright (JIRA)]

Karl Wright created LUCENE-8187:
---

 Summary: Spatial3d test times out 1/3 of the time
 Key: LUCENE-8187
 URL: https://issues.apache.org/jira/browse/LUCENE-8187
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial3d
Reporter: Karl Wright
Assignee: Karl Wright
 Attachments: image-2018-02-27-15-42-14-460.png

Reproduce with:

{code}
ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testRandomBig 
-Dtests.seed=CD4A0C5760E678E6 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.locale=is -Dtests.timezone=America/Martinique 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
{code}




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

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

Re: Test failures are out of control......

[Karl Wright]

I looked at the Geo3d failures; these are timeouts exclusively.  I suspect
we're seeing a test issue.  Will try to correct.

Karl


On Tue, Feb 27, 2018 at 1:51 PM, Chris Hostetter 
wrote:

> : The most interesting bit is probably here...
> :
> :   http://fucit.org/solr-jenkins-reports/failure-report.html
>
> FYI:
>
> I realized this morning that the "Suite Runs" counts were being
> artificially inflated for suites that are frequently SKIPPED (either
> because they are @Nighly or @Slow and not run by all jenkins jobs).  I've
> now fixed this, so at a glance the "suite level" failure rates are
> much higher today then they have been if you looked at it in the past.
>
> It means it's also now possible for a Suite failure rate to be greater
> then 100%, because sometimes it's reporting multiple suite level failures
> for a single run.
>
>
> Other follow up on some previous comments...
>
> : 1) there's some noise inthe '7days' data because I wasn't accounting for
> : the way jenkins reports some types of failure -- that will gradually
> clean
> : itself up
>
> ...some of these "Class: xml" failures are still visible in the report but
> should drop off over the next few days
>
> : 2) I think i've been been blocked by builds.apache.org, so at the moment
> : the data seems to just be from the sarowe & policeman jenkins failures.
>
> ...this is fixed.
>
> : 3) allthough the system is archiving the past 7 days worth of jenkins
> logs
> : for any jobs with failures, there is currently no easy way to download
> : the relevant log(s) from that failure report -- you currently have to
>
> ...this is also fixed.  now if you click on any row in the test you'll get
> a pop up showing you a link to all the job-data dirs that recorded a
> failure on that report view.  The most recent jobs are listed first.
>
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[JENKINS] Lucene-Solr-repro - Build # 156 - Still Unstable

[Apache Jenkins Server]

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

[...truncated 30 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-7.x/465/consoleText

[repro] Revision: 186475fc3d5ab6d433966166c0bb747f3e103b75

[repro] Repro line:  ant test  -Dtestcase=TestJmxIntegration 
-Dtests.method=testJmxOnCoreReload -Dtests.seed=1CCC375C77EB19CC 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=be 
-Dtests.timezone=America/Anchorage -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestRequestStatusCollectionAPI 
-Dtests.method=test -Dtests.seed=1CCC375C77EB19CC -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=et -Dtests.timezone=Etc/GMT-1 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=ZkControllerTest 
-Dtests.method=testPublishAndWaitForDownStates -Dtests.seed=1CCC375C77EB19CC 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=en-US 
-Dtests.timezone=Asia/Kathmandu -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=SSLMigrationTest 
-Dtests.seed=1CCC375C77EB19CC -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=pl -Dtests.timezone=Pacific/Samoa -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestReplicationHandler 
-Dtests.method=doTestIndexFetchOnMasterRestart -Dtests.seed=1CCC375C77EB19CC 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=de-CH 
-Dtests.timezone=Asia/Pontianak -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=AtomicUpdateProcessorFactoryTest 
-Dtests.method=testMultipleThreads -Dtests.seed=1CCC375C77EB19CC 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ar-JO 
-Dtests.timezone=Europe/Vienna -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestLTRReRankingPipeline 
-Dtests.method=testDifferentTopN -Dtests.seed=FF2C2346C0DA0CC1 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=es-ES 
-Dtests.timezone=America/Cambridge_Bay -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: 
d512cd7604741a2f55deb0c840188f0342f1ba57
[repro] git fetch
[repro] git checkout 186475fc3d5ab6d433966166c0bb747f3e103b75

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

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

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/contrib/ltr
[repro]   TestLTRReRankingPipeline
[repro]solr/core
[repro]   TestRequestStatusCollectionAPI
[repro]   TestJmxIntegration
[repro]   AtomicUpdateProcessorFactoryTest
[repro]   ZkControllerTest
[repro]   TestReplicationHandler
[repro]   SSLMigrationTest
[repro] ant compile-test

[...truncated 2579 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestLTRReRankingPipeline" -Dtests.showOutput=onerror  
-Dtests.seed=FF2C2346C0DA0CC1 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=es-ES -Dtests.timezone=America/Cambridge_Bay 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

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

[repro] ant compile-test

[...truncated 1331 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=30 
-Dtests.class="*.TestRequestStatusCollectionAPI|*.TestJmxIntegration|*.AtomicUpdateProcessorFactoryTest|*.ZkControllerTest|*.TestReplicationHandler|*.SSLMigrationTest"
 -Dtests.showOutput=onerror  -Dtests.seed=1CCC375C77EB19CC -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=et -Dtests.timezone=Etc/GMT-1 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

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

[repro] Failures:
[repro]   0/5 failed: 
org.apache.solr.cloud.api.collections.TestRequestStatusCollectionAPI
[repro]   2/5 failed: 
org.apache.solr.update.processor.AtomicUpdateProcessorFactoryTest
[repro]   5/5 failed: org.apache.solr.cloud.SSLMigrationTest
[repro]   5/5 failed: org.apache.solr.cloud.ZkControllerTest
[repro]   5/5 failed: org.apache.solr.core.TestJmxIntegration
[repro]   5/5 failed: org.apache.solr.handler.TestReplicationHandler
[repro]   5/5 failed: org.apache.solr.ltr.TestLTRReRankingPipeline

[repro] Re-testing 100% failures at the tip of branch_7x
[repro] ant clean

[...truncated 8 lines...]
[repro] Test suites by module:
[repro]solr/contrib/ltr
[repro]   TestLTRReRankingPipeline
[repro]solr/core
[repro]   ZkControllerTest
[repro]   TestReplicationHandler
[repro]   TestJmxIntegration
[repro]   SSLMigrationTest
[repro] ant compile-test

[...truncated 2579 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestLTRReRankingPipeline" -Dtests.showOutput=onerror  
-Dtests.seed=FF2C2346C0DA0CC1 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=es-ES 

[jira] [Commented] (SOLR-12040) HdfsBasicDistributedZkTest & HdfsBasicDistributedZk2 fail on virtually every jenkins run

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-12040:


Yeah, but not likely till this weekend. Stuck in Vegas like a frog in a pot. 

> HdfsBasicDistributedZkTest & HdfsBasicDistributedZk2 fail on virtually every 
> jenkins run
> 
>
> Key: SOLR-12040
> URL: https://issues.apache.org/jira/browse/SOLR-12040
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Mark Miller
>Priority: Major
>
> HdfsBasicDistributedZkTest & HdfsBasicDistributedZk2 are thin subclasses of 
> BasicDistributedZkTest & BasicDistributedZk2 that just tweak the setup to use 
> HDFS, and only run @Nightly.
> These tests are failing virtually every time they are run by jenkins - either 
> at a method level, or at a suite level (due to threadleaks, timeouts, etc...) 
> yet their non-HDFS superclasss virtually never fail.
> Per the jenkins failure rates reports i've setup, here's the failure rates of 
> all tests matching "BasicDistributed" for the past 7days (note that the 
> non-HDFS tests aren't even listed, because they haven't failed at all even 
> though they are non-nightly and have cumulatively run ~750 times in the past 
> 7 days)
> http://fucit.org/solr-jenkins-reports/failure-report.html
> {noformat}
> "Suite?","Class","Method","Rate","Runs","Fails"
> "true","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZk2Test","","53.3","15","8"
> "false","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZk2Test","test","18.75","16","3"
> "true","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZkTest","","46.1538461538462","13","6"
> "false","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZkTest","test","7.69230769230769","13","1"
> {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] [Resolved] (LUCENE-5575) Non-reproducible TestICUTokenizerCJK failure

[Erick Erickson (JIRA)]

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

Erick Erickson resolved LUCENE-5575.

   Resolution: Fixed
Fix Version/s: 7.3

> Non-reproducible TestICUTokenizerCJK failure
> 
>
> Key: LUCENE-5575
> URL: https://issues.apache.org/jira/browse/LUCENE-5575
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 6.0
>Reporter: Michael McCandless
>Priority: Major
> Fix For: 7.3
>
>
> TestICUTokenizerCJK.testRandomHugeStrings -seed 3D1F79CAB506E300
> It hit this failure during distributed beasting:
> {noformat}
> FAILURE: org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK on 
> host 10.17.4.101
> java.lang.RuntimeException: some thread(s) failed
>   at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:533)
>   at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:435)
>   at 
> org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK.testRandomHugeStrings(TestICUTokenizerCJK.java:89)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:360)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:793)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:453)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[jira] [Commented] (LUCENE-5575) Non-reproducible TestICUTokenizerCJK failure

[Erick Erickson (JIRA)]

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

Erick Erickson commented on LUCENE-5575:


Beasted 1,000 times last night without annotation so I commented the AwaitsFix 
out with today's date so we can track if this was premature.

> Non-reproducible TestICUTokenizerCJK failure
> 
>
> Key: LUCENE-5575
> URL: https://issues.apache.org/jira/browse/LUCENE-5575
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 6.0
>Reporter: Michael McCandless
>Priority: Major
>
> TestICUTokenizerCJK.testRandomHugeStrings -seed 3D1F79CAB506E300
> It hit this failure during distributed beasting:
> {noformat}
> FAILURE: org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK on 
> host 10.17.4.101
> java.lang.RuntimeException: some thread(s) failed
>   at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:533)
>   at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:435)
>   at 
> org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK.testRandomHugeStrings(TestICUTokenizerCJK.java:89)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:360)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:793)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:453)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
>

[jira] [Commented] (LUCENE-5575) Non-reproducible TestICUTokenizerCJK failure

[ASF subversion and git services (JIRA)]

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

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

Commit a730beb4fbe2e35fed4f7fd2cc110d9eaf3aa83e in lucene-solr's branch 
refs/heads/branch_7x from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a730beb ]

LUCENE-5575: Non-reproducible TestICUTokenizerCJK failure

(cherry picked from commit 7de694e)


> Non-reproducible TestICUTokenizerCJK failure
> 
>
> Key: LUCENE-5575
> URL: https://issues.apache.org/jira/browse/LUCENE-5575
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 6.0
>Reporter: Michael McCandless
>Priority: Major
>
> TestICUTokenizerCJK.testRandomHugeStrings -seed 3D1F79CAB506E300
> It hit this failure during distributed beasting:
> {noformat}
> FAILURE: org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK on 
> host 10.17.4.101
> java.lang.RuntimeException: some thread(s) failed
>   at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:533)
>   at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:435)
>   at 
> org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK.testRandomHugeStrings(TestICUTokenizerCJK.java:89)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:360)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:793)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:453)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> 

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.4) - Build # 1441 - Still Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLowerTerms

Error Message:
Doc with id=5 not found in 
http://127.0.0.1:37773/forceleader_lower_terms_collection due to: Path not 
found: /id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=5 not found in 
http://127.0.0.1:37773/forceleader_lower_terms_collection due to: Path not 
found: /id; rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([3EFBA32EEB1792AB:B0CF836D2BB032DF]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:700)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:645)
at 
org.apache.solr.cloud.ForceLeaderTest.bringBackOldLeaderAndSendDoc(ForceLeaderTest.java:521)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLowerTerms(ForceLeaderTest.java:158)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[jira] [Commented] (LUCENE-5575) Non-reproducible TestICUTokenizerCJK failure

[ASF subversion and git services (JIRA)]

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

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

Commit 7de694e7713ef59ac6b578c0f8ee10759dd6a30e in lucene-solr's branch 
refs/heads/master from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7de694e ]

LUCENE-5575: Non-reproducible TestICUTokenizerCJK failure


> Non-reproducible TestICUTokenizerCJK failure
> 
>
> Key: LUCENE-5575
> URL: https://issues.apache.org/jira/browse/LUCENE-5575
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 6.0
>Reporter: Michael McCandless
>Priority: Major
>
> TestICUTokenizerCJK.testRandomHugeStrings -seed 3D1F79CAB506E300
> It hit this failure during distributed beasting:
> {noformat}
> FAILURE: org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK on 
> host 10.17.4.101
> java.lang.RuntimeException: some thread(s) failed
>   at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:533)
>   at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:435)
>   at 
> org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK.testRandomHugeStrings(TestICUTokenizerCJK.java:89)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:360)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:793)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:453)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> 

[jira] [Assigned] (SOLR-12040) HdfsBasicDistributedZkTest & HdfsBasicDistributedZk2 fail on virtually every jenkins run

[Hoss Man (JIRA)]

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

Hoss Man reassigned SOLR-12040:
---

Assignee: Mark Miller

FWIW: I've poked around in the jenkins logs (for jobs where there are failures 
at both the method level and suite level) looking for any red flags in the solr 
log messages and couldn't find anything obvious – there are occasional 
InteruptedExceptions logged by the HDFS layer, and TriggerInjection 
occasionally complains that a node is out of sync with the leader – but i see 
these same types of exceptions in the logs when i run the tests locally and it 
passes.

[~markrmil...@gmail.com]: can you please help diagnose these failures?

> HdfsBasicDistributedZkTest & HdfsBasicDistributedZk2 fail on virtually every 
> jenkins run
> 
>
> Key: SOLR-12040
> URL: https://issues.apache.org/jira/browse/SOLR-12040
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Mark Miller
>Priority: Major
>
> HdfsBasicDistributedZkTest & HdfsBasicDistributedZk2 are thin subclasses of 
> BasicDistributedZkTest & BasicDistributedZk2 that just tweak the setup to use 
> HDFS, and only run @Nightly.
> These tests are failing virtually every time they are run by jenkins - either 
> at a method level, or at a suite level (due to threadleaks, timeouts, etc...) 
> yet their non-HDFS superclasss virtually never fail.
> Per the jenkins failure rates reports i've setup, here's the failure rates of 
> all tests matching "BasicDistributed" for the past 7days (note that the 
> non-HDFS tests aren't even listed, because they haven't failed at all even 
> though they are non-nightly and have cumulatively run ~750 times in the past 
> 7 days)
> http://fucit.org/solr-jenkins-reports/failure-report.html
> {noformat}
> "Suite?","Class","Method","Rate","Runs","Fails"
> "true","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZk2Test","","53.3","15","8"
> "false","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZk2Test","test","18.75","16","3"
> "true","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZkTest","","46.1538461538462","13","6"
> "false","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZkTest","test","7.69230769230769","13","1"
> {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-12040) HdfsBasicDistributedZkTest & HdfsBasicDistributedZk2 fail on virtually every jenkins run

[Hoss Man (JIRA)]

Hoss Man created SOLR-12040:
---

 Summary: HdfsBasicDistributedZkTest & HdfsBasicDistributedZk2 fail 
on virtually every jenkins run
 Key: SOLR-12040
 URL: https://issues.apache.org/jira/browse/SOLR-12040
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


HdfsBasicDistributedZkTest & HdfsBasicDistributedZk2 are thin subclasses of 
BasicDistributedZkTest & BasicDistributedZk2 that just tweak the setup to use 
HDFS, and only run @Nightly.

These tests are failing virtually every time they are run by jenkins - either 
at a method level, or at a suite level (due to threadleaks, timeouts, etc...) 
yet their non-HDFS superclasss virtually never fail.

Per the jenkins failure rates reports i've setup, here's the failure rates of 
all tests matching "BasicDistributed" for the past 7days (note that the 
non-HDFS tests aren't even listed, because they haven't failed at all even 
though they are non-nightly and have cumulatively run ~750 times in the past 7 
days)

http://fucit.org/solr-jenkins-reports/failure-report.html

{noformat}
"Suite?","Class","Method","Rate","Runs","Fails"
"true","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZk2Test","","53.3","15","8"
"false","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZk2Test","test","18.75","16","3"
"true","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZkTest","","46.1538461538462","13","6"
"false","org.apache.solr.cloud.hdfs.HdfsBasicDistributedZkTest","test","7.69230769230769","13","1"
{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-SmokeRelease-master - Build # 965 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 28738 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 491 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] Java 9 JAVA_HOME=/home/jenkins/tools/java/latest1.9
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (18.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-8.0.0-src.tgz...
   [smoker] 30.2 MB in 0.03 sec (1150.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.tgz...
   [smoker] 73.2 MB in 0.06 sec (1148.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.zip...
   [smoker] 83.7 MB in 0.07 sec (1160.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6243 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6243 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6243 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6243 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.badapples=false 
-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 212 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 9 and testArgs='-Dtests.badapples=false 
-Dtests.slow=false'...
   [smoker] test demo with 9...
   [smoker]   got 212 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (99.5 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-8.0.0-src.tgz...
   [smoker] 52.6 MB in 0.45 sec (117.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.tgz...
   [smoker] 151.0 MB in 2.09 sec (72.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.zip...
   [smoker] 152.0 MB in 2.00 sec (76.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-8.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21546/
Java: 32bit/jdk1.8.0_162 -server -XX:+UseSerialGC

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

Error Message:
Waiting for collection testSimple1 null Live Nodes: [127.0.0.1:35107_solr, 
127.0.0.1:36787_solr] Last available state: 
DocCollection(testSimple1//collections/testSimple1/state.json/14)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{  
 "range":"8000-",   "state":"active",   "replicas":{
 "core_node3":{   
"dataDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node3/data/",
   "base_url":"http://127.0.0.1:35107/solr;,   
"node_name":"127.0.0.1:35107_solr",   "type":"NRT",   
"ulogDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node3/data/tlog",
   "core":"testSimple1_shard1_replica_n1",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node5":{   
"dataDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node5/data/",
   "base_url":"http://127.0.0.1:35107/solr;,   
"node_name":"127.0.0.1:35107_solr",   "type":"NRT",   
"ulogDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node5/data/tlog",
   "core":"testSimple1_shard1_replica_n2",   
"shared_storage":"true",   "state":"active"}}}, "shard2":{   
"range":"0-7fff",   "state":"active",   "replicas":{ 
"core_node7":{   
"dataDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node7/data/",
   "base_url":"http://127.0.0.1:35107/solr;,   
"node_name":"127.0.0.1:35107_solr",   "type":"NRT",   
"ulogDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node7/data/tlog",
   "core":"testSimple1_shard2_replica_n4",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node8":{   
"dataDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node8/data/",
   "base_url":"http://127.0.0.1:39747/solr;,   
"node_name":"127.0.0.1:39747_solr",   "type":"NRT",   
"ulogDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node8/data/tlog",
   "core":"testSimple1_shard2_replica_n6",   
"shared_storage":"true",   "state":"down",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"true",   "nrtReplicas":"2",   "tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Waiting for collection testSimple1
null
Live Nodes: [127.0.0.1:35107_solr, 127.0.0.1:36787_solr]
Last available state: 
DocCollection(testSimple1//collections/testSimple1/state.json/14)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{
"shard1":{
  "range":"8000-",
  "state":"active",
  "replicas":{
"core_node3":{
  
"dataDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node3/data/",
  "base_url":"http://127.0.0.1:35107/solr;,
  "node_name":"127.0.0.1:35107_solr",
  "type":"NRT",
  
"ulogDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node3/data/tlog",
  "core":"testSimple1_shard1_replica_n1",
  "shared_storage":"true",
  "state":"active",
  "leader":"true"},
"core_node5":{
  
"dataDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node5/data/",
  "base_url":"http://127.0.0.1:35107/solr;,
  "node_name":"127.0.0.1:35107_solr",
  "type":"NRT",
  
"ulogDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node5/data/tlog",
  "core":"testSimple1_shard1_replica_n2",
  "shared_storage":"true",
  "state":"active"}}},
"shard2":{
  "range":"0-7fff",
  "state":"active",
  "replicas":{
"core_node7":{
  
"dataDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node7/data/",
  "base_url":"http://127.0.0.1:35107/solr;,
  "node_name":"127.0.0.1:35107_solr",
  "type":"NRT",
  
"ulogDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node7/data/tlog",
  "core":"testSimple1_shard2_replica_n4",
  "shared_storage":"true",
  "state":"active",
  "leader":"true"},
"core_node8":{
  
"dataDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node8/data/",
  "base_url":"http://127.0.0.1:39747/solr;,
  "node_name":"127.0.0.1:39747_solr",
  "type":"NRT",
  
"ulogDir":"hdfs://localhost.localdomain:36449/data/testSimple1/core_node8/data/tlog",
  "core":"testSimple1_shard2_replica_n6",
  "shared_storage":"true",
  

Re: Test failures are out of control......

[Chris Hostetter]

: The most interesting bit is probably here...
: 
:   http://fucit.org/solr-jenkins-reports/failure-report.html

FYI:

I realized this morning that the "Suite Runs" counts were being 
artificially inflated for suites that are frequently SKIPPED (either 
because they are @Nighly or @Slow and not run by all jenkins jobs).  I've 
now fixed this, so at a glance the "suite level" failure rates are 
much higher today then they have been if you looked at it in the past.

It means it's also now possible for a Suite failure rate to be greater 
then 100%, because sometimes it's reporting multiple suite level failures 
for a single run.


Other follow up on some previous comments...

: 1) there's some noise inthe '7days' data because I wasn't accounting for 
: the way jenkins reports some types of failure -- that will gradually clean 
: itself up

...some of these "Class: xml" failures are still visible in the report but 
should drop off over the next few days

: 2) I think i've been been blocked by builds.apache.org, so at the moment 
: the data seems to just be from the sarowe & policeman jenkins failures.

...this is fixed.

: 3) allthough the system is archiving the past 7 days worth of jenkins logs 
: for any jobs with failures, there is currently no easy way to download 
: the relevant log(s) from that failure report -- you currently have to 

...this is also fixed.  now if you click on any row in the test you'll get 
a pop up showing you a link to all the job-data dirs that recorded a 
failure on that report view.  The most recent jobs are listed first.



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

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

Re: Lucene/Solr 7.3

[Cassandra Targett]

I intend to create the Ref Guide RC as soon as the Lucene/Solr artifacts RC
is ready, so this is a great time to remind folks that if you've got Ref
Guide changes to be done, you've got a couple weeks. If you're stuck or not
sure what to do, let me know & I'm happy to help you out.

Eventually we'd like to release both the Ref Guide and Lucene/Solr with the
same release process, so this will be a big first test to see how ready for
that we are.

On Tue, Feb 27, 2018 at 11:42 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> +1
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Fri, Feb 23, 2018 at 4:50 AM, Alan Woodward <
> alan.woodw...@romseysoftware.co.uk> wrote:
>
>> Hi all,
>>
>> It’s been a couple of months since the 7.2 release, and we’ve accumulated
>> some nice new features since then.  I’d like to volunteer to be RM for a
>> 7.3 release.
>>
>> I’m travelling for the next couple of weeks, so I would plan to create
>> the release branch two weeks today, on the 9th March (unless anybody else
>> wants to do it sooner, of course :)
>>
>> - Alan
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>

[jira] [Updated] (SOLR-11956) Collapsing on undefined field returns 500

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-11956:
-
Component/s: query parsers

> Collapsing on undefined field returns 500
> -
>
> Key: SOLR-11956
> URL: https://issues.apache.org/jira/browse/SOLR-11956
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Reporter: Munendra S N
>Priority: Trivial
> Attachments: SOLR-11956.patch, SOLR-11956.patch, SOLR-11956.patch
>
>
> When collapsing is specified on the undefined field then, the response 
> returned has status 500 instead of 400. 
> This is because of wrapping of SolrException to RuntimeException
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/CollapsingQParserPlugin.java#L377
> Then in request handler base, all RuntimeException are converted to 
> SolrException with status 500



--
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-11955) Clean up usage of graph token filters in shipped schemas

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-11955:
-
Component/s: Schema and Analysis
 examples

> Clean up usage of graph token filters in shipped schemas
> 
>
> Key: SOLR-11955
> URL: https://issues.apache.org/jira/browse/SOLR-11955
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: examples, Schema and Analysis
>Reporter: Steve Rowe
>Priority: Major
>
> I noted in a thread on the solr-user mailing list  
> [https://lists.apache.org/thread.html/557347c2e22352ae3b2ccd9e9f22fbf8ce50d8efed901901adf020fc@%3Csolr-user.lucene.apache.org%3E]
>  that token graph filters (e.g. SynonymGraphFilter and 
> WordDelimiterGraphFilter) can't handle input graphs, i.e. streams produced by 
> other token graph filters.
> From the above-linked thread, [~WebHomer] wrote:
> {quote}
> I noticed that in some of the current example schemas that are shipped with
> Solr, there is a fieldtype, text_en_splitting, that feeds the output
> of SynonymGraphFilterFactory into WordDelimiterGraphFilterFactory. So if
> this isn't supported, the example should probably be updated or removed.
> {quote}
> We should evaluate all analysis chains in shipped schemas to address this.



--
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-12013) collections API CUSTERSTATUS command fails when collections have errors

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12013:
-
Component/s: SolrCloud

> collections API CUSTERSTATUS command fails when collections have errors
> ---
>
> Key: SOLR-12013
> URL: https://issues.apache.org/jira/browse/SOLR-12013
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.0, 7.0, 7.1, 7.2
>Reporter: Ben DeMott
>Priority: Major
>
> CLUSTERSTATUS command can be given independent of a given collection.
> http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
> I would expect that you can still inspect the status of a cluster even if a 
> single collection has failed, or is missing its configuration.
> *Expected behavior*: all healthy collections status is returned, unhealthy 
> collections are either reported with a stacktrace in the response, reported 
> in a failure state, or are not present from the response.
> For example, CLUSTERSTATUS fails when a collection config-set is missing from 
> ZooKeeper with:
> {{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not 
> exist in ZooKeeper: config-set-name*}}
> {{ *at 
> org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}}
> {{ at 
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}}
> {{ at 
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}}
> {{ at 
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}}
> {{ at 
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}}
> {{ at 
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}}
> {{ at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}}
> {{ at 
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}}
> {{ at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}}
> {{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}}
> {{ at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}}
> {{ at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}}
> {{ at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}}
> {{ at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)}}
> {{ at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)}}
> {{ at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)}}
> {{ at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)}}
> {{ at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)}}
> {{ at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)}}
> {{ at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)}}
> {{ at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)}}
> {{ at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)}}
> {{ at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)}}
> {{ at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)}}
> {{ at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)}}
> {{ at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at org.eclipse.jetty.server.Server.handle(Server.java:534)}}
> {{ at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)}}
> {{ at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)}}
> {{ at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)}}
> {{ at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)}}
> {{ at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)}}
> {{ at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)}}
> {{ at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)}}
> {{ at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)}}
> {{ at 
> 

[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-12028:
---

bq. BadApple tests should be run often enough to give various summaries 
something to report on

I think I saw weekly frequency suggested elsewhere for badapple tests, but then 
Hoss's 7-day summary won't have much to work with.  I think daily is a better 
frequency.

I'll set up daily job with badapple=true for master and branch_7x, and another 
set of weekly jobs with nightly=true & badapples=true (there are a few tests 
with this annotation combination), on both Apache and my Jenkins.

[~thetaphi], do you want to host badapple tests on Policeman Jenkins?


> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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 # 155 - Still Unstable

[Apache Jenkins Server]

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

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

[repro] Revision: d512cd7604741a2f55deb0c840188f0342f1ba57

[repro] Repro line:  ant test  -Dtestcase=TestReplicationHandler 
-Dtests.method=doTestIndexFetchOnMasterRestart -Dtests.seed=F068AD5978FF7DBF 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=hr-HR 
-Dtests.timezone=Asia/Karachi -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=TestJmxIntegration 
-Dtests.method=testJmxOnCoreReload -Dtests.seed=F068AD5978FF7DBF 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=es-PE 
-Dtests.timezone=America/Tegucigalpa -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=AtomicUpdateProcessorFactoryTest 
-Dtests.method=testMultipleThreads -Dtests.seed=F068AD5978FF7DBF 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=de-GR 
-Dtests.timezone=Canada/Central -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=ZkControllerTest 
-Dtests.method=testPublishAndWaitForDownStates -Dtests.seed=F068AD5978FF7DBF 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=th -Dtests.timezone=WET 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=SSLMigrationTest 
-Dtests.seed=F068AD5978FF7DBF -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=sq-AL -Dtests.timezone=Asia/Seoul -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=TestLTRReRankingPipeline 
-Dtests.method=testDifferentTopN -Dtests.seed=646C4FA12964C65C 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=zh 
-Dtests.timezone=Antarctica/Palmer -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: 
d512cd7604741a2f55deb0c840188f0342f1ba57
[repro] git fetch
[repro] git checkout d512cd7604741a2f55deb0c840188f0342f1ba57

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

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

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/contrib/ltr
[repro]   TestLTRReRankingPipeline
[repro]solr/core
[repro]   ZkControllerTest
[repro]   AtomicUpdateProcessorFactoryTest
[repro]   TestJmxIntegration
[repro]   TestReplicationHandler
[repro]   SSLMigrationTest
[repro] ant compile-test

[...truncated 2563 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestLTRReRankingPipeline" -Dtests.showOutput=onerror  
-Dtests.seed=646C4FA12964C65C -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=zh -Dtests.timezone=Antarctica/Palmer -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

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

[repro] ant compile-test

[...truncated 1329 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=25 
-Dtests.class="*.ZkControllerTest|*.AtomicUpdateProcessorFactoryTest|*.TestJmxIntegration|*.TestReplicationHandler|*.SSLMigrationTest"
 -Dtests.showOutput=onerror  -Dtests.seed=F068AD5978FF7DBF -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=th -Dtests.timezone=WET -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures:
[repro]   5/5 failed: org.apache.solr.cloud.SSLMigrationTest
[repro]   5/5 failed: org.apache.solr.cloud.ZkControllerTest
[repro]   5/5 failed: org.apache.solr.core.TestJmxIntegration
[repro]   5/5 failed: org.apache.solr.handler.TestReplicationHandler
[repro]   5/5 failed: org.apache.solr.ltr.TestLTRReRankingPipeline
[repro]   5/5 failed: 
org.apache.solr.update.processor.AtomicUpdateProcessorFactoryTest

[repro] Re-testing 100% failures at the tip of master
[repro] ant clean

[...truncated 8 lines...]
[repro] Test suites by module:
[repro]solr/contrib/ltr
[repro]   TestLTRReRankingPipeline
[repro]solr/core
[repro]   ZkControllerTest
[repro]   AtomicUpdateProcessorFactoryTest
[repro]   TestJmxIntegration
[repro]   TestReplicationHandler
[repro]   SSLMigrationTest
[repro] ant compile-test

[...truncated 2563 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestLTRReRankingPipeline" -Dtests.showOutput=onerror  
-Dtests.seed=646C4FA12964C65C -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=zh -Dtests.timezone=Antarctica/Palmer -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

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

[repro] ant compile-test

[...truncated 1329 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=25 

[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-12028:
---

[~steve_rowe] Fair enough. I expect it to take a bit to make this smooth. 
Here's the goal as I see it, subject to negotiation. How we work it out is TBD:

Tests that are always broken are AwaitsFix. These won't be run regularly. I'm 
going to provide a report each week (just an e-mail to the dev list) with the 
current tests with either AwaitsFix or BadApple annotations.

BadApple tests should be run often enough to give various summaries something 
to report on (e.g. Hoss' report, your work). Personally I'm going to filter 
them to a special folder that I can examine at leisure.

Anything run with tests.badapples=false that fails requires immediate 
attention. For a short while that may just be adding BadApple annotations. When 
things settle down, adding more BadApple annotations should only rarely be done.




> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-11670) Implement a periodic house-keeping task

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-11670:
--

Patch containing the following:
 * a {{MaintenanceTask}} API that components may use for registering tasks with 
Overseer. Tasks are initialized using key / value pairs from 
{{/clusterprops.json}}
 * {{MaintenanceTasks}} component, which is a registry and runner of tasks. 
This component also monitors changes to {{/clusterprops.json}} and 
re-initializes tasks and their schedule as needed.
 * implementation of {{InactiveSliceCleanupTask}}, which deletes inactive 
slices that exceeded a configured TTL time. This task is registered by 
{{SplitShardCmd}}.
 * changes to {{SplitShardTest}} to exercise this code.

This code is also available on branch {{jira/solr-11670}}.

> Implement a periodic house-keeping task
> ---
>
> Key: SOLR-11670
> URL: https://issues.apache.org/jira/browse/SOLR-11670
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-11670.patch
>
>
> Some high-impact cluster changes (such as split shard) leave the original 
> data and original state that is no longer actively used. This makes sense due 
> to safety reasons and to make it easier to roll-back the changes.
> However, this unused data will accumulate over time, especially when actions 
> like split shard are invoked automatically by the autoscaling framework. We 
> need a periodic task that would clean up this kind of data after a certain 
> period.



--
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-11670) Implement a periodic house-keeping task

[Andrzej Bialecki (JIRA)]

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

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

> Implement a periodic house-keeping task
> ---
>
> Key: SOLR-11670
> URL: https://issues.apache.org/jira/browse/SOLR-11670
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-11670.patch
>
>
> Some high-impact cluster changes (such as split shard) leave the original 
> data and original state that is no longer actively used. This makes sense due 
> to safety reasons and to make it easier to roll-back the changes.
> However, this unused data will accumulate over time, especially when actions 
> like split shard are invoked automatically by the autoscaling framework. We 
> need a periodic task that would clean up this kind of data after a certain 
> period.



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

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

Re: Lucene/Solr 7.3

[Michael McCandless]

+1

Mike McCandless

http://blog.mikemccandless.com

On Fri, Feb 23, 2018 at 4:50 AM, Alan Woodward <
alan.woodw...@romseysoftware.co.uk> wrote:

> Hi all,
>
> It’s been a couple of months since the 7.2 release, and we’ve accumulated
> some nice new features since then.  I’d like to volunteer to be RM for a
> 7.3 release.
>
> I’m travelling for the next couple of weeks, so I would plan to create the
> release branch two weeks today, on the 9th March (unless anybody else wants
> to do it sooner, of course :)
>
> - Alan
> -
> 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-Linux (64bit/jdk-10-ea+43) - Build # 1440 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1440/
Java: 64bit/jdk-10-ea+43 -XX:-UseCompressedOops -XX:+UseG1GC

11 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLowerTerms

Error Message:
Doc with id=5 not found in 
http://127.0.0.1:36405/kt/forceleader_lower_terms_collection due to: Path not 
found: /id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=5 not found in 
http://127.0.0.1:36405/kt/forceleader_lower_terms_collection due to: Path not 
found: /id; rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([EBDD0DBA803F6542:65E92DF94098C536]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:700)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:645)
at 
org.apache.solr.cloud.ForceLeaderTest.bringBackOldLeaderAndSendDoc(ForceLeaderTest.java:521)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLowerTerms(ForceLeaderTest.java:158)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-12028:
---

bq. Uwe Schindler Are we going to set up some number of runs with 
badapples=false? Any of those that fail need immediate attention...

IMHO, the vast majority of Jenkins runs should be configured with 
badapples=false.  I'll go change every one of the existing jobs right now.

[~erickerickson], I think your question should be rephrased: "Once all Jenkins 
runs are configured badapples=false, are we going to set up some number of runs 
with badapples=true?"

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 2386 - Still Unstable

[Apache Jenkins Server]

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

9 tests failed.
FAILED:  org.apache.solr.cloud.TestAuthenticationFramework.testBasics

Error Message:
Error from server at 
http://127.0.0.1:59533/solr/testcollection_shard1_replica_n2: Expected mime 
type application/octet-stream but got text/html.Error 404 
Can not find: /solr/testcollection_shard1_replica_n2/update  
HTTP ERROR 404 Problem accessing 
/solr/testcollection_shard1_replica_n2/update. Reason: Can not find: 
/solr/testcollection_shard1_replica_n2/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.8.v20171121  
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:59533/solr/testcollection_shard1_replica_n2: 
Expected mime type application/octet-stream but got text/html. 


Error 404 Can not find: 
/solr/testcollection_shard1_replica_n2/update

HTTP ERROR 404
Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason:
Can not find: 
/solr/testcollection_shard1_replica_n2/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.8.v20171121




at 
__randomizedtesting.SeedInfo.seed([B199F550DA2D3A63:8C415B7CE2C36413]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:550)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1013)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
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.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.TestAuthenticationFramework.collectionCreateSearchDeleteTwice(TestAuthenticationFramework.java:127)
at 
org.apache.solr.cloud.TestAuthenticationFramework.testBasics(TestAuthenticationFramework.java:75)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-12028:
---

bq. Steve Rowe Right, but this is expected since tests.badapples=true is the 
default. 

Um, clearly I haven't been following closely enough, but: a regime that 
guarantees failed Jenkins runs 100% of the time is the opposite of useful.

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-12028) BadApple and AwaitsFix annotations usage

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-12028:
---

One more, from 
[http://jenkins.sarowe.net/job/Lucene-Solr-reproduce-failed-tests/1772/], 
reproducing failures on 
[http://jenkins.sarowe.net/job/Lucene-Solr-tests-master/15265/]:

{noformat}
[repro] Failures at the tip of master without a seed:
[...]
[repro]   5/5 failed: 
org.apache.solr.update.processor.AtomicUpdateProcessorFactoryTest
{noformat}


> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-9510) child level facet exclusions

[Dr Oleg Savrasov (JIRA)]

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

Dr Oleg Savrasov commented on SOLR-9510:


All the remaining *TODO* items are elaborated

> child level facet exclusions
> 
>
> Key: SOLR-9510
> URL: https://issues.apache.org/jira/browse/SOLR-9510
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, faceting, query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-9510.patch, SOLR_9510.patch, SOLR_9510.patch, 
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, 
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch
>
>
> h2. Challenge
> * Since SOLR-5743 achieved block join child level facets with counts roll-up 
> to parents, there is a demand for filter exclusions. 
> h2. Context
> * Then, it's worth to consider JSON Facets as an engine for this 
> functionality rather than support a separate component. 
> * During a discussion in SOLR-8998 [a solution for block join with child 
> level 
> exclusion|https://issues.apache.org/jira/browse/SOLR-8998?focusedCommentId=15487095=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15487095]
>  has been found.  
>
> h2. Proposal
> It's proposed to provide a bit of syntax sugar to make it user friendly, 
> believe it or not.
> h2. List of improvements
> * introducing a local parameter {{filters}} for {{\{!parent}} query parser 
> referring to _multiple_ filters queries via parameter name: {{\{!parent 
> filters=$child.fq ..}..=color:Red=size:XL}} 
> these _filters_ are intersected with a child query supplied as a subordinate 
> clause.
> * introducing {{\{!filters params=$child.fq excludeTags=color 
> v=$subq}=text:word={!tag=color}color:Red=size:XL}} it 
> intersects a subordinate clause (here it's {{subq}} param, and the trick is 
> to refer to the same query from {{\{!parent}}}), with multiple filters 
> supplied via parameter name {{params=$child.fq}}, it also supports 
> {{excludeTags}}.
> h2. Notes
> Regarding the latter parser, the alternative approach might be to move into 
> {{domain:\{..}}} instruction of json facet. From the implementation 
> perspective, it's desired to optimize with bitset processing, however I 
> suppose it's might be deferred until some initial level of maturity. 
> h2. Example
> {code}
> q={!parent which=type_s:book filters=$child.fq 
> v=$childquery}=comment_t:good={!tag=author}author_s:yonik={!tag=stars}stars_i:(5
>  3)=json=on={
> comments_for_author:{
>   type:query,
>   q:"{!filters params=$child.fq excludeTags=author v=$childquery}",
>   "//note":"author filter is excluded",
>   domain:{
>  blockChildren:"type_s:book",
>  "//":"applying filters here might be more promising"
>}, facet:{
>authors:{
>   type:terms,
>   field:author_s,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>}
> } ,
> comments_for_stars:{
>   type:query,
>  q:"{!filters params=$child.fq excludeTags=stars v=$childquery}",
>   "//note":"stars_i filter is excluded",
>   domain:{
>  blockChildren:"type_s:book"
>}, facet:{
>stars:{
>   type:terms,
>   field:stars_i,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>   }
> }
> }
> {code} 
> Votes? Opinions?



--
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] [Issue Comment Deleted] (SOLR-9510) child level facet exclusions

[Dr Oleg Savrasov (JIRA)]

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

Dr Oleg Savrasov updated SOLR-9510:
---
Comment: was deleted

(was: All the remaining *TODO* items are elaborated)

> child level facet exclusions
> 
>
> Key: SOLR-9510
> URL: https://issues.apache.org/jira/browse/SOLR-9510
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, faceting, query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-9510.patch, SOLR_9510.patch, SOLR_9510.patch, 
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, 
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch
>
>
> h2. Challenge
> * Since SOLR-5743 achieved block join child level facets with counts roll-up 
> to parents, there is a demand for filter exclusions. 
> h2. Context
> * Then, it's worth to consider JSON Facets as an engine for this 
> functionality rather than support a separate component. 
> * During a discussion in SOLR-8998 [a solution for block join with child 
> level 
> exclusion|https://issues.apache.org/jira/browse/SOLR-8998?focusedCommentId=15487095=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15487095]
>  has been found.  
>
> h2. Proposal
> It's proposed to provide a bit of syntax sugar to make it user friendly, 
> believe it or not.
> h2. List of improvements
> * introducing a local parameter {{filters}} for {{\{!parent}} query parser 
> referring to _multiple_ filters queries via parameter name: {{\{!parent 
> filters=$child.fq ..}..=color:Red=size:XL}} 
> these _filters_ are intersected with a child query supplied as a subordinate 
> clause.
> * introducing {{\{!filters params=$child.fq excludeTags=color 
> v=$subq}=text:word={!tag=color}color:Red=size:XL}} it 
> intersects a subordinate clause (here it's {{subq}} param, and the trick is 
> to refer to the same query from {{\{!parent}}}), with multiple filters 
> supplied via parameter name {{params=$child.fq}}, it also supports 
> {{excludeTags}}.
> h2. Notes
> Regarding the latter parser, the alternative approach might be to move into 
> {{domain:\{..}}} instruction of json facet. From the implementation 
> perspective, it's desired to optimize with bitset processing, however I 
> suppose it's might be deferred until some initial level of maturity. 
> h2. Example
> {code}
> q={!parent which=type_s:book filters=$child.fq 
> v=$childquery}=comment_t:good={!tag=author}author_s:yonik={!tag=stars}stars_i:(5
>  3)=json=on={
> comments_for_author:{
>   type:query,
>   q:"{!filters params=$child.fq excludeTags=author v=$childquery}",
>   "//note":"author filter is excluded",
>   domain:{
>  blockChildren:"type_s:book",
>  "//":"applying filters here might be more promising"
>}, facet:{
>authors:{
>   type:terms,
>   field:author_s,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>}
> } ,
> comments_for_stars:{
>   type:query,
>  q:"{!filters params=$child.fq excludeTags=stars v=$childquery}",
>   "//note":"stars_i filter is excluded",
>   domain:{
>  blockChildren:"type_s:book"
>}, facet:{
>stars:{
>   type:terms,
>   field:stars_i,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>   }
> }
> }
> {code} 
> Votes? Opinions?



--
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-9510) child level facet exclusions

[Dr Oleg Savrasov (JIRA)]

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

Dr Oleg Savrasov updated SOLR-9510:
---
Attachment: SOLR_9510.patch

> child level facet exclusions
> 
>
> Key: SOLR-9510
> URL: https://issues.apache.org/jira/browse/SOLR-9510
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, faceting, query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-9510.patch, SOLR_9510.patch, SOLR_9510.patch, 
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, 
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch
>
>
> h2. Challenge
> * Since SOLR-5743 achieved block join child level facets with counts roll-up 
> to parents, there is a demand for filter exclusions. 
> h2. Context
> * Then, it's worth to consider JSON Facets as an engine for this 
> functionality rather than support a separate component. 
> * During a discussion in SOLR-8998 [a solution for block join with child 
> level 
> exclusion|https://issues.apache.org/jira/browse/SOLR-8998?focusedCommentId=15487095=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15487095]
>  has been found.  
>
> h2. Proposal
> It's proposed to provide a bit of syntax sugar to make it user friendly, 
> believe it or not.
> h2. List of improvements
> * introducing a local parameter {{filters}} for {{\{!parent}} query parser 
> referring to _multiple_ filters queries via parameter name: {{\{!parent 
> filters=$child.fq ..}..=color:Red=size:XL}} 
> these _filters_ are intersected with a child query supplied as a subordinate 
> clause.
> * introducing {{\{!filters params=$child.fq excludeTags=color 
> v=$subq}=text:word={!tag=color}color:Red=size:XL}} it 
> intersects a subordinate clause (here it's {{subq}} param, and the trick is 
> to refer to the same query from {{\{!parent}}}), with multiple filters 
> supplied via parameter name {{params=$child.fq}}, it also supports 
> {{excludeTags}}.
> h2. Notes
> Regarding the latter parser, the alternative approach might be to move into 
> {{domain:\{..}}} instruction of json facet. From the implementation 
> perspective, it's desired to optimize with bitset processing, however I 
> suppose it's might be deferred until some initial level of maturity. 
> h2. Example
> {code}
> q={!parent which=type_s:book filters=$child.fq 
> v=$childquery}=comment_t:good={!tag=author}author_s:yonik={!tag=stars}stars_i:(5
>  3)=json=on={
> comments_for_author:{
>   type:query,
>   q:"{!filters params=$child.fq excludeTags=author v=$childquery}",
>   "//note":"author filter is excluded",
>   domain:{
>  blockChildren:"type_s:book",
>  "//":"applying filters here might be more promising"
>}, facet:{
>authors:{
>   type:terms,
>   field:author_s,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>}
> } ,
> comments_for_stars:{
>   type:query,
>  q:"{!filters params=$child.fq excludeTags=stars v=$childquery}",
>   "//note":"stars_i filter is excluded",
>   domain:{
>  blockChildren:"type_s:book"
>}, facet:{
>stars:{
>   type:terms,
>   field:stars_i,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>   }
> }
> }
> {code} 
> Votes? Opinions?



--
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-9510) child level facet exclusions

[Dr Oleg Savrasov (JIRA)]

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

Dr Oleg Savrasov updated SOLR-9510:
---
Attachment: SOLR_9510.patch

> child level facet exclusions
> 
>
> Key: SOLR-9510
> URL: https://issues.apache.org/jira/browse/SOLR-9510
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, faceting, query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-9510.patch, SOLR_9510.patch, SOLR_9510.patch, 
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, 
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch
>
>
> h2. Challenge
> * Since SOLR-5743 achieved block join child level facets with counts roll-up 
> to parents, there is a demand for filter exclusions. 
> h2. Context
> * Then, it's worth to consider JSON Facets as an engine for this 
> functionality rather than support a separate component. 
> * During a discussion in SOLR-8998 [a solution for block join with child 
> level 
> exclusion|https://issues.apache.org/jira/browse/SOLR-8998?focusedCommentId=15487095=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15487095]
>  has been found.  
>
> h2. Proposal
> It's proposed to provide a bit of syntax sugar to make it user friendly, 
> believe it or not.
> h2. List of improvements
> * introducing a local parameter {{filters}} for {{\{!parent}} query parser 
> referring to _multiple_ filters queries via parameter name: {{\{!parent 
> filters=$child.fq ..}..=color:Red=size:XL}} 
> these _filters_ are intersected with a child query supplied as a subordinate 
> clause.
> * introducing {{\{!filters params=$child.fq excludeTags=color 
> v=$subq}=text:word={!tag=color}color:Red=size:XL}} it 
> intersects a subordinate clause (here it's {{subq}} param, and the trick is 
> to refer to the same query from {{\{!parent}}}), with multiple filters 
> supplied via parameter name {{params=$child.fq}}, it also supports 
> {{excludeTags}}.
> h2. Notes
> Regarding the latter parser, the alternative approach might be to move into 
> {{domain:\{..}}} instruction of json facet. From the implementation 
> perspective, it's desired to optimize with bitset processing, however I 
> suppose it's might be deferred until some initial level of maturity. 
> h2. Example
> {code}
> q={!parent which=type_s:book filters=$child.fq 
> v=$childquery}=comment_t:good={!tag=author}author_s:yonik={!tag=stars}stars_i:(5
>  3)=json=on={
> comments_for_author:{
>   type:query,
>   q:"{!filters params=$child.fq excludeTags=author v=$childquery}",
>   "//note":"author filter is excluded",
>   domain:{
>  blockChildren:"type_s:book",
>  "//":"applying filters here might be more promising"
>}, facet:{
>authors:{
>   type:terms,
>   field:author_s,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>}
> } ,
> comments_for_stars:{
>   type:query,
>  q:"{!filters params=$child.fq excludeTags=stars v=$childquery}",
>   "//note":"stars_i filter is excluded",
>   domain:{
>  blockChildren:"type_s:book"
>}, facet:{
>stars:{
>   type:terms,
>   field:stars_i,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>   }
> }
> }
> {code} 
> Votes? Opinions?



--
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-12028) BadApple and AwaitsFix annotations usage

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-12028:
---

[~steve_rowe] Right, but this is expected since tests.badapples=true is the 
default. I'm setting up a mail filter to funnel any report that does _not_ have 
tests.badapples=false to a special folder.

[~thetaphi] Are we going to set up some number of runs with badapples=false? 
Any of _those_ that fail need immediate attention...

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-9510) child level facet exclusions

[Dr Oleg Savrasov (JIRA)]

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

Dr Oleg Savrasov updated SOLR-9510:
---
Attachment: (was: SOLR_9510.patch)

> child level facet exclusions
> 
>
> Key: SOLR-9510
> URL: https://issues.apache.org/jira/browse/SOLR-9510
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, faceting, query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-9510.patch, SOLR_9510.patch, SOLR_9510.patch, 
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, 
> SOLR_9510.patch
>
>
> h2. Challenge
> * Since SOLR-5743 achieved block join child level facets with counts roll-up 
> to parents, there is a demand for filter exclusions. 
> h2. Context
> * Then, it's worth to consider JSON Facets as an engine for this 
> functionality rather than support a separate component. 
> * During a discussion in SOLR-8998 [a solution for block join with child 
> level 
> exclusion|https://issues.apache.org/jira/browse/SOLR-8998?focusedCommentId=15487095=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15487095]
>  has been found.  
>
> h2. Proposal
> It's proposed to provide a bit of syntax sugar to make it user friendly, 
> believe it or not.
> h2. List of improvements
> * introducing a local parameter {{filters}} for {{\{!parent}} query parser 
> referring to _multiple_ filters queries via parameter name: {{\{!parent 
> filters=$child.fq ..}..=color:Red=size:XL}} 
> these _filters_ are intersected with a child query supplied as a subordinate 
> clause.
> * introducing {{\{!filters params=$child.fq excludeTags=color 
> v=$subq}=text:word={!tag=color}color:Red=size:XL}} it 
> intersects a subordinate clause (here it's {{subq}} param, and the trick is 
> to refer to the same query from {{\{!parent}}}), with multiple filters 
> supplied via parameter name {{params=$child.fq}}, it also supports 
> {{excludeTags}}.
> h2. Notes
> Regarding the latter parser, the alternative approach might be to move into 
> {{domain:\{..}}} instruction of json facet. From the implementation 
> perspective, it's desired to optimize with bitset processing, however I 
> suppose it's might be deferred until some initial level of maturity. 
> h2. Example
> {code}
> q={!parent which=type_s:book filters=$child.fq 
> v=$childquery}=comment_t:good={!tag=author}author_s:yonik={!tag=stars}stars_i:(5
>  3)=json=on={
> comments_for_author:{
>   type:query,
>   q:"{!filters params=$child.fq excludeTags=author v=$childquery}",
>   "//note":"author filter is excluded",
>   domain:{
>  blockChildren:"type_s:book",
>  "//":"applying filters here might be more promising"
>}, facet:{
>authors:{
>   type:terms,
>   field:author_s,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>}
> } ,
> comments_for_stars:{
>   type:query,
>  q:"{!filters params=$child.fq excludeTags=stars v=$childquery}",
>   "//note":"stars_i filter is excluded",
>   domain:{
>  blockChildren:"type_s:book"
>}, facet:{
>stars:{
>   type:terms,
>   field:stars_i,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>   }
> }
> }
> {code} 
> Votes? Opinions?



--
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-8998) JSON Facet API child roll-ups

[Dr Oleg Savrasov (JIRA)]

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

Dr Oleg Savrasov updated SOLR-8998:
---
Attachment: SOLR_8998.patch

> JSON Facet API child roll-ups
> -
>
> Key: SOLR-8998
> URL: https://issues.apache.org/jira/browse/SOLR-8998
> Project: Solr
>  Issue Type: New Feature
>  Components: Facet Module
>Reporter: Yonik Seeley
>Priority: Major
> Attachments: SOLR_8998.patch, SOLR_8998.patch, SOLR_8998.patch
>
>
> The JSON Facet API currently has the ability to map between parents and 
> children ( see http://yonik.com/solr-nested-objects/ )
> This issue is about adding a true rollup ability where parents would take on 
> derived values from their children.  The most important part (and the most 
> difficult part) will be the external API.



--
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-12028) BadApple and AwaitsFix annotations usage

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-12028:
---

>From [http://jenkins.sarowe.net/job/Lucene-Solr-reproduce-failed-tests/1760/], 
>reproducing failures on 
>[http://jenkins.sarowe.net/job/Lucene-Solr-tests-master/15259/]: 

{noformat}
[repro] Failures at the tip of master without a seed:
[repro]   5/5 failed: org.apache.solr.cloud.SSLMigrationTest
[repro]   5/5 failed: org.apache.solr.cloud.ZkControllerTest
[repro]   5/5 failed: org.apache.solr.core.TestJmxIntegration
[repro]   5/5 failed: org.apache.solr.handler.TestReplicationHandler
[repro]   5/5 failed: org.apache.solr.ltr.TestLTRReRankingPipeline
{noformat}

>From [https://builds.apache.org/job/Lucene-Solr-repro/154/], reproducing 
>failures on [https://builds.apache.org/job/Lucene-Solr-Tests-7.x/464/]:
 
{noformat}
[repro] Failures at the tip of branch_7x without a seed:
[repro]   5/5 failed: org.apache.solr.cloud.SSLMigrationTest
[repro]   5/5 failed: org.apache.solr.cloud.ZkControllerTest
[repro]   5/5 failed: org.apache.solr.core.TestJmxIntegration
[repro]   5/5 failed: org.apache.solr.handler.TestReplicationHandler
[repro]   5/5 failed: org.apache.solr.ltr.TestLTRReRankingPipeline
{noformat}



> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
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-8998) JSON Facet API child roll-ups

[Dr Oleg Savrasov (JIRA)]

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

Dr Oleg Savrasov commented on SOLR-8998:


Latest patch is adjusted to use MultiAcc.[^SOLR_8998.patch]

> JSON Facet API child roll-ups
> -
>
> Key: SOLR-8998
> URL: https://issues.apache.org/jira/browse/SOLR-8998
> Project: Solr
>  Issue Type: New Feature
>  Components: Facet Module
>Reporter: Yonik Seeley
>Priority: Major
> Attachments: SOLR_8998.patch, SOLR_8998.patch, SOLR_8998.patch
>
>
> The JSON Facet API currently has the ability to map between parents and 
> children ( see http://yonik.com/solr-nested-objects/ )
> This issue is about adding a true rollup ability where parents would take on 
> derived values from their children.  The most important part (and the most 
> difficult part) will be the external API.



--
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 # 465 - Still Unstable

[Apache Jenkins Server]

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

8 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.TestRequestStatusCollectionAPI.test

Error Message:
Error from server at http://127.0.0.1:39888: KeeperErrorCode = Session expired 
for /overseer/collection-map-completed/mn-1001

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:39888: KeeperErrorCode = Session expired for 
/overseer/collection-map-completed/mn-1001
at 
__randomizedtesting.SeedInfo.seed([1CCC375C77EB19CC:94980886D9177434]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.api.collections.TestRequestStatusCollectionAPI.sendRequest(TestRequestStatusCollectionAPI.java:194)
at 
org.apache.solr.cloud.api.collections.TestRequestStatusCollectionAPI.sendStatusRequestWithRetry(TestRequestStatusCollectionAPI.java:167)
at 
org.apache.solr.cloud.api.collections.TestRequestStatusCollectionAPI.test(TestRequestStatusCollectionAPI.java:107)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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