[jira] [Commented] (LUCENE-7035) upgrade icu4j to latest (unicode 8)

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7035:
---

Hi Robert, I also regenerated inside analysis/common, because this one creates 
the UnicodeWhitespaceTokenizer's data file from icu4j.jar. This actually did 
not change anything, but the file versions were updated.

Maybe we should add a message in analysis/icu's build.xml that reminds you to 
also update the analysis/common files if you update ICU.

> upgrade icu4j to latest (unicode 8)
> ---
>
> Key: LUCENE-7035
> URL: https://issues.apache.org/jira/browse/LUCENE-7035
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-7035.patch
>
>
> See LUCENE-6993.
> We want to bring all these tokenizers up to date. The icu part can be done 
> independently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7035) upgrade icu4j to latest (unicode 8)

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7035: Also regenerate analysis/common's UnicodeWhitespaceTokenizer (it 
actually changes nothing, but updates version numbers)


> upgrade icu4j to latest (unicode 8)
> ---
>
> Key: LUCENE-7035
> URL: https://issues.apache.org/jira/browse/LUCENE-7035
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-7035.patch
>
>
> See LUCENE-6993.
> We want to bring all these tokenizers up to date. The icu part can be done 
> independently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 841 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/841/

2 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication

Error Message:
[/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_29636712B3A9A70E-001/solr-instance-026/./collection1/data,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_29636712B3A9A70E-001/solr-instance-026/./collection1/data/index.20160218075752930,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_29636712B3A9A70E-001/solr-instance-026/./collection1/data/index.20160218075753018]
 expected:<2> but was:<3>

Stack Trace:
java.lang.AssertionError: 
[/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_29636712B3A9A70E-001/solr-instance-026/./collection1/data,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_29636712B3A9A70E-001/solr-instance-026/./collection1/data/index.20160218075752930,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_29636712B3A9A70E-001/solr-instance-026/./collection1/data/index.20160218075753018]
 expected:<2> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([29636712B3A9A70E:DE10894A754108E8]: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.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:815)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1245)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3978 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3978/

2 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication

Error Message:
Index: 0, Size: 0

Stack Trace:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at 
__randomizedtesting.SeedInfo.seed([628E59FDA777E331:95FDB7A5619F4CD7]:0)
at java.util.ArrayList.rangeCheck(ArrayList.java:635)
at java.util.ArrayList.get(ArrayList.java:411)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1241)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.index.hdfs.CheckHdfsIndexTest.doTest

Error Message:
Could not find a healthy node to handle the request.

Stack Trace:
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request.
at 

[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_72) - Build # 5626 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5626/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample

Error Message:
Could not find a healthy node to handle the request.

Stack Trace:
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request.
at 
__randomizedtesting.SeedInfo.seed([386CBB4A658EBF4C:E31D5B8052FB7A2A]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1084)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample(TestSolrCLIRunExample.java:446)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_72) - Build # 15917 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15917/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample

Error Message:
Could not find a healthy node to handle the request.

Stack Trace:
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request.
at 
__randomizedtesting.SeedInfo.seed([A48D3B037D41E324:7FFCDBC94A342642]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1084)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample(TestSolrCLIRunExample.java:446)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (LUCENE-6993) Update TLDs to latest list

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6993:
-

I took care of the icu parts here: LUCENE-7035

please ping me here if you have trouble setting up the back compat. I can 
always do that part, if it gets too frustrating. But it is better if more 
people can do it.

> Update TLDs to latest list
> --
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk-9-ea+105) - Build # 15607 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15607/
Java: 64bit/jdk-9-ea+105 -XX:+UseCompressedOops -XX:+UseG1GC -XX:-UseSuperWord

2 tests failed.
FAILED:  
org.apache.lucene.search.TestMinShouldMatch2.testNextVaryingNumberOfTerms

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([8A2C7EE93B6A4127:75FDE26C61843946]:0)
at 
org.apache.lucene.search.BooleanScorer.scoreWindowIntoBitSetAndReplay(BooleanScorer.java:218)
at 
org.apache.lucene.search.BooleanScorer.scoreWindowMultipleScorers(BooleanScorer.java:266)
at 
org.apache.lucene.search.BooleanScorer.scoreWindow(BooleanScorer.java:311)
at org.apache.lucene.search.BooleanScorer.score(BooleanScorer.java:335)
at 
org.apache.lucene.search.BulkScorerWrapperScorer.refill(BulkScorerWrapperScorer.java:52)
at 
org.apache.lucene.search.BulkScorerWrapperScorer.access$500(BulkScorerWrapperScorer.java:25)
at 
org.apache.lucene.search.BulkScorerWrapperScorer$2.advance(BulkScorerWrapperScorer.java:101)
at 
org.apache.lucene.search.BulkScorerWrapperScorer$2.nextDoc(BulkScorerWrapperScorer.java:95)
at 
org.apache.lucene.search.TestMinShouldMatch2.assertNext(TestMinShouldMatch2.java:157)
at 
org.apache.lucene.search.TestMinShouldMatch2.testNextVaryingNumberOfTerms(TestMinShouldMatch2.java:278)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[JENKINS-EA] Lucene-Solr-5.5-Linux (64bit/jdk-9-ea+105) - Build # 35 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/35/
Java: 64bit/jdk-9-ea+105 -XX:-UseCompressedOops -XX:+UseParallelGC 
-XX:-UseSuperWord

1 tests failed.
FAILED:  
org.apache.lucene.util.TestQueryBuilder.testPhraseQueryPositionIncrements

Error Message:
6

Stack Trace:
java.lang.ArrayIndexOutOfBoundsException: 6
at 
__randomizedtesting.SeedInfo.seed([B81D7DB1DE2C71DA:9A56C9E54DA9F1EF]:0)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:524)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
at 
org.apache.lucene.util.TestQueryBuilder.testPhraseQueryPositionIncrements(TestQueryBuilder.java:110)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:804)




Build Log:
[...truncated 540 lines...]
   [junit4] Suite: org.apache.lucene.util.TestQueryBuilder
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestQueryBuilder 
-Dtests.method=testPhraseQueryPositionIncrements -Dtests.seed=B81D7DB1DE2C71DA 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=bg 
-Dtests.timezone=Asia/Baghdad -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_72) - Build # 15916 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15916/
Java: 32bit/jdk1.8.0_72 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample

Error Message:
Could not find a healthy node to handle the request.

Stack Trace:
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request.
at 
__randomizedtesting.SeedInfo.seed([79BF6360E059BB6E:A2CE83AAD72C7E08]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1084)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample(TestSolrCLIRunExample.java:446)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Resolved] (LUCENE-7035) upgrade icu4j to latest (unicode 8)

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-7035.
-
Resolution: Fixed

> upgrade icu4j to latest (unicode 8)
> ---
>
> Key: LUCENE-7035
> URL: https://issues.apache.org/jira/browse/LUCENE-7035
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-7035.patch
>
>
> See LUCENE-6993.
> We want to bring all these tokenizers up to date. The icu part can be done 
> independently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7035) upgrade icu4j to latest (unicode 8)

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7035: Upgrade icu4j to 56.1/unicode 8.


> upgrade icu4j to latest (unicode 8)
> ---
>
> Key: LUCENE-7035
> URL: https://issues.apache.org/jira/browse/LUCENE-7035
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-7035.patch
>
>
> See LUCENE-6993.
> We want to bring all these tokenizers up to date. The icu part can be done 
> independently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7035) upgrade icu4j to latest (unicode 8)

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7035:


+1

> upgrade icu4j to latest (unicode 8)
> ---
>
> Key: LUCENE-7035
> URL: https://issues.apache.org/jira/browse/LUCENE-7035
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-7035.patch
>
>
> See LUCENE-6993.
> We want to bring all these tokenizers up to date. The icu part can be done 
> independently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-7035) upgrade icu4j to latest (unicode 8)

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7035:

Attachment: LUCENE-7035.patch

Here's a patch (does not include regenerated binary changes).

It bumps the version, removes khmer syllable segmentation in favor of ICU's 
khmer support (and adds test), and regenerates all data files.

> upgrade icu4j to latest (unicode 8)
> ---
>
> Key: LUCENE-7035
> URL: https://issues.apache.org/jira/browse/LUCENE-7035
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-7035.patch
>
>
> See LUCENE-6993.
> We want to bring all these tokenizers up to date. The icu part can be done 
> independently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-7035) upgrade icu4j to latest (unicode 8)

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7035:
---

 Summary: upgrade icu4j to latest (unicode 8)
 Key: LUCENE-7035
 URL: https://issues.apache.org/jira/browse/LUCENE-7035
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Robert Muir
 Fix For: 6.0


See LUCENE-6993.

We want to bring all these tokenizers up to date. The icu part can be done 
independently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8029) Modernize and standardize Solr APIs

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8029:
---

Commit 5893631766d9908de56a714885a23d028add014f in lucene-solr's branch 
refs/heads/apiv2 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5893631 ]

SOLR-8029 By default, do not register all APIs to the v2 path


> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: master
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: master
>
> Attachments: SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch, 
> SOLR-8029.patch
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 4 types of requests in the new API 
> * {{/v2//*}} : Hit a collection directly or manage 
> collections/shards/replicas 
> * {{/v2//*}} : Hit a core directly or manage cores 
> * {{/v2/cluster/*}} : Operations on cluster not pertaining to any collection 
> or core. e.g: security, overseer ops etc
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6993) Update TLDs to latest list

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6993:
-

And i guess really we should call it {{std50}} to keep things simple. if 
someone asks for 5.4 compatibility, they should get this one and then the logic 
in the Analyzer will be clear that is the case even going forward.

> Update TLDs to latest list
> --
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6993) Update TLDs to latest list

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6993:
-

Basically the old versions of the Tokenizer and Impl are just "saved" to a 
subdirectory, and in the Analyzer and TokenizerFactory we conditionally use 
them, if you request that compatibility version.

Have a look at branch_5x which still has {{std40}} containing 
StandardTokenizer40, StandardTokenizerImpl40, UAX29URLEmailTokenizer40, and so 
on. TestStandardAnalyzer and TestUAX29URLEmailAnalyzer also have a 
testBackcompat40 which calls {{setVersion}} and ensures it works. Finally, see 
StandardAnalyzer/TokenizerFactory.java, and 
UAXURLEmailAnalyzer/TokenizerFactory.java which conditionally use 
StandardTokenizer40 depending on version.

So we should do a similar thing with the current stuff in master before 
modifying the files, and make them {{std55}}. We can just test that it works at 
all (e.g. foo bar -> foo,bar) initially and later maybe add a test ensuring 
"old behavior" stays the same.

Then you can bump unicode version and tld lists and it won't change any 
behavior if someone asks for version < 6.0, because they will get the exact 
same tokenizer as before.

> Update TLDs to latest list
> --
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8588) Add TopicStream to the streaming API to support publish/subscribe messaging

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8588:
-
Attachment: SOLR-8588.patch

Added tests for checkpointing during read() iteration.

> Add TopicStream to the streaming API to support publish/subscribe messaging
> ---
>
> Key: SOLR-8588
> URL: https://issues.apache.org/jira/browse/SOLR-8588
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-8588.patch, SOLR-8588.patch, SOLR-8588.patch, 
> SOLR-8588.patch, SOLR-8588.patch
>
>
> The TopicStream is a *publish/subscribe messaging service* built on top of 
> SolrCloud.  The TopicStream returns all *new* documents for a specific query. 
> Version numbers will be used as checkpoints for Topics to ensure single 
> delivery of each document. When combined with the DaemonStream (SOLR-8550), 
> Topics can provide continuous streaming. Sample syntax:
> {code}
> topic(checkpointCollection, dataCollection, id="topicA",  q="awesome stuff" 
> checkpointEvery="1000")
> {code}
> The checkpoint collection will be used to persist the topic checkpoints.
> Example combined with the DaemonStream:
> {code}
> daemon(topic(...)...)
> {code}
> When combined with SOLR-7739 this allows for messaging based on *machine 
> learned* classifications.
> The TopicStream supports 3 models of publish/subscribe messaging:
> 1) *Request & response*: In this model a topic(...) expression can be saved 
> and executed at any time. In this scenario the TopicStream will always 
> retrieve it's checkpoints and start from where it left off.
> 2) *Continuous pull streaming*: In this model you would wrap the TopicStream 
> in a DaemonStream and call read() in a loop inside a java program.  This 
> would provide a continuous stream of new content as it arrives in the index.
> 3) *Continuous push streaming*: In this model you would send an expression 
> like this to the /stream handler: *daemon(update(topic(...)...)...)*. This 
> daemon process would run inside Solr and continuously stream new documents 
> from the topic and push them to another SolrCloud collection. Other pushing 
> expressions can be created to push documents in different ways or take other 
> types of actions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8588) Add TopicStream to the streaming API to support publish/subscribe messaging

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8588:
--

Next step is manual testing.

> Add TopicStream to the streaming API to support publish/subscribe messaging
> ---
>
> Key: SOLR-8588
> URL: https://issues.apache.org/jira/browse/SOLR-8588
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-8588.patch, SOLR-8588.patch, SOLR-8588.patch, 
> SOLR-8588.patch, SOLR-8588.patch
>
>
> The TopicStream is a *publish/subscribe messaging service* built on top of 
> SolrCloud.  The TopicStream returns all *new* documents for a specific query. 
> Version numbers will be used as checkpoints for Topics to ensure single 
> delivery of each document. When combined with the DaemonStream (SOLR-8550), 
> Topics can provide continuous streaming. Sample syntax:
> {code}
> topic(checkpointCollection, dataCollection, id="topicA",  q="awesome stuff" 
> checkpointEvery="1000")
> {code}
> The checkpoint collection will be used to persist the topic checkpoints.
> Example combined with the DaemonStream:
> {code}
> daemon(topic(...)...)
> {code}
> When combined with SOLR-7739 this allows for messaging based on *machine 
> learned* classifications.
> The TopicStream supports 3 models of publish/subscribe messaging:
> 1) *Request & response*: In this model a topic(...) expression can be saved 
> and executed at any time. In this scenario the TopicStream will always 
> retrieve it's checkpoints and start from where it left off.
> 2) *Continuous pull streaming*: In this model you would wrap the TopicStream 
> in a DaemonStream and call read() in a loop inside a java program.  This 
> would provide a continuous stream of new content as it arrives in the index.
> 3) *Continuous push streaming*: In this model you would send an expression 
> like this to the /stream handler: *daemon(update(topic(...)...)...)*. This 
> daemon process would run inside Solr and continuously stream new documents 
> from the topic and push them to another SolrCloud collection. Other pushing 
> expressions can be created to push documents in different ways or take other 
> types of actions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6993) Update TLDs to latest list

[Mike Drob (JIRA)]

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

Mike Drob updated LUCENE-6993:
--
Attachment: LUCENE-6993.patch

>From {{analysis/common}} directory, I ran {{ANT_OPTS="-Xmx6g" ant gen-tlds 
>unicode-data jflex}}

Do I need to manually update the {{%unicode X.X}} directive in the .jflex files 
or do we want to leave that for compatibility? I am unclear on the impacts here.

Also, I did not see any previous examples of keeping the tokenizers around for 
compatibility, so I guess I didn't quite understand where the hooks are. 

> Update TLDs to latest list
> --
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [VOTE] Release Lucene/Solr 5.5.0 RC3

[Nicholas Knize]

+1

SUCCESS! [1:23:31.568510]

On Wed, Feb 17, 2016 at 2:41 PM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> +1
>
> SUCCESS! [1:07:58.838693]
>
> On Tue, Feb 16, 2016 at 1:07 PM, Michael McCandless
>  wrote:
> > Please vote for the RC3 release candidate for Lucene/Solr 5.5.0, the
> > last feature release before Lucene 6.0.0 and the first Lucene/Solr
> > release since we switched from Subversion to git!
> >
> > Artifacts:
> >
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.0-RC3-rev2a228b3920a07f930f7afb6a42d0d20e184a943c
> >
> > Smoke tester:
> >
> >   python3 -u dev-tools/scripts/smokeTestRelease.py
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.0-RC3-rev2a228b3920a07f930f7afb6a42d0d20e184a943c
> >
> > Please remember a release is not the time to shove last minute changes
> > in.  Instead, shove those changes in immediately after the release so
> > CI has plenty of time to chew on them.
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 3038 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/3038/
Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test

Error Message:
Error from server at http://127.0.0.1:54794/o_/b/awholynewcollection_0: non ok 
status: 500, message:Server Error

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:54794/o_/b/awholynewcollection_0: non ok 
status: 500, message:Server Error
at 
__randomizedtesting.SeedInfo.seed([3ECF26845C57B0C7:B69B195EF2ABDD3F]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:510)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForNon403or404or503(AbstractFullDistribZkTestBase.java:1753)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:737)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:160)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (LUCENE-6993) Update TLDs to latest list

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6993:
-

OK, I can look into the icu part in a separate issue, since its somewhat 
unrelated but I think worthwhile for consistency.

> Update TLDs to latest list
> --
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6993) Update TLDs to latest list

[Mike Drob (JIRA)]

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

Mike Drob commented on LUCENE-6993:
---

That all makes sense. I was looking at the unicode spec changes between 6.3 and 
8.0 and did not really understand what the impact to our grammars is.

I'll add the current grammar to a std55 directory, but will need some help 
making sure that I've got all the right back-compat hooks. I'll post an updated 
patch shortly when I get stuck.

> Update TLDs to latest list
> --
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (LUCENE-6993) Update TLDs to latest list

[Robert Muir (JIRA)]

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

Robert Muir reassigned LUCENE-6993:
---

Assignee: Robert Muir

> Update TLDs to latest list
> --
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6993) Update TLDs to latest list

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-6993:

Fix Version/s: 6.0

> Update TLDs to latest list
> --
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6993) Update TLDs to latest list

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6993:
-

I with a major release looming we should update all this stuff. Also the 
unicode version (and icu library) to Unicode 8.0 because java has already done 
this for JDK 9 (http://openjdk.java.net/jeps/267), and we should not fall so 
far behind. 

We should copy the current generated grammar with a 'std55' subdirectory and 
hook it in for backwards compatibility before applying grammar changes. Then I 
think just fix all this stuff at once? It sounds worse than it is, I think it 
can be done today, I will help.



> Update TLDs to latest list
> --
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 840 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/840/

2 tests failed.
FAILED:  org.apache.solr.search.TestIndexSearcher.testReopen

Error Message:
expected:<_0(6.0.0):C2> but was:<_3(6.0.0):c6>

Stack Trace:
java.lang.AssertionError: expected:<_0(6.0.0):C2> but was:<_3(6.0.0):c6>
at 
__randomizedtesting.SeedInfo.seed([D182CE444F24E904:FDCA1F523C186627]: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:147)
at 
org.apache.solr.search.TestIndexSearcher.testReopen(TestIndexSearcher.java:121)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample

Error Message:
Could not find a healthy node to handle the request.

Stack Trace:
org.apache.solr.common.SolrException: Could not find 

[jira] [Commented] (LUCENE-6993) Update TLDs to latest list

[Mike Drob (JIRA)]

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

Mike Drob commented on LUCENE-6993:
---

[~rcmuir] - Do you have any thoughts on this since you were involved in the 
previous patch too?

> Update TLDs to latest list
> --
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
> Attachments: LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7734) MapReduce Indexer can error when using secure collection

[Mike Drob (JIRA)]

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

Mike Drob updated SOLR-7734:

Summary: MapReduce Indexer can error when using secure collection  (was: 
MapReduce Indexer can error when using collection)

> MapReduce Indexer can error when using secure collection
> 
>
> Key: SOLR-7734
> URL: https://issues.apache.org/jira/browse/SOLR-7734
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Affects Versions: 5.2.1
>Reporter: Mike Drob
>Assignee: Gregory Chanan
> Fix For: 5.5, master
>
> Attachments: SOLR-7734.branch5x.patch, SOLR-7734.patch, 
> SOLR-7734.patch, SOLR-7734.patch, SOLR-7734.patch, SOLR-7734.patch, 
> SOLR-7734.patch, SOLR-7734.patch
>
>
> When running the MapReduceIndexerTool, it will usually pull a 
> {{solrconfig.xml}} from ZK for the collection that it is running against. 
> This can be problematic for several reasons:
> * Performance: The configuration in ZK will likely have several query 
> handlers, and lots of other components that don't make sense in an 
> indexing-only use of EmbeddedSolrServer (ESS).
> * Classpath Resources: If the Solr services are using some kind of additional 
> service (such as Sentry for auth) then the indexer will not have access to 
> the necessary configurations without the user jumping through several hoops.
> * Distinct Configuration Needs: Enabling Soft Commits on the ESS doesn't make 
> sense. There's other configurations that 
> * Update Chain Behaviours: I'm under the impression that UpdateChains may 
> behave differently in ESS than a SolrCloud cluster. Is it safe to depend on 
> consistent behaviour here?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_72) - Build # 15915 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15915/
Java: 32bit/jdk1.8.0_72 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample

Error Message:
Could not find a healthy node to handle the request.

Stack Trace:
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request.
at 
__randomizedtesting.SeedInfo.seed([513DD2224788F90B:8A4C32E870FD3C6D]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1084)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample(TestSolrCLIRunExample.java:446)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

Re: ZK related startup fixes -- pre-review requested?

[Scott Blum]

Awesome, thanks Shalin!

On Wed, Feb 17, 2016 at 3:21 PM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> Hi Scott,
>
> Those all sound very important fixes. I skimmed the changes and they
> all look good to me. I think the ZkController changes are
> straightforward. The leader election changes should get some more eyes
> (maybe Mark Miller can chime in) but please do open the jira issues
> (preferably separate ones for easier review+commit).
>
> Thanks!
>
> On Mon, Feb 15, 2016 at 1:59 PM, Scott Blum  wrote:
> > Hi folks (paticularly Erick and Shalin),
> >
> > Before I go through the cycle of creating JIRAs and requesting formal
> > review, I wondered if I could get some feedback on some work I've been
> doing
> > to allow SolrCloud to startup faster and more reliably.
> >
> > Problems:
> >
> > 1) Quickly restarting a node makes leader election unreliable; the
> existing
> > ZK node hasn't yet disappeared and confuses the current logic.  I
> believe I
> > have fixed this and simplified the logic.  This affects overseer
> election.
> >
> > 2) ZkController.publishAndWaitForDownStates() occurs before overseer
> > election.  That means if there is currently no overseer, there is
> ironically
> > no one to actually service the down state changes it's waiting on.  This
> > particularly affects a single-node cluster such as you might run locally
> for
> > development.
> >
> > 3) Audited our current implementations of process(WatchedEvent) for
> > consistency and handling edge cases.
> >
> > 4) Simplified DistributedMap; there's a whole lot more API surface area
> and
> > implementation machinery than we're using.
> >
> > Code is here: https://github.com/fullstorydev/lucene-solr/pull/1
> > The individual commits might be informative.
> >
> > Would some some feedback, and if these seem reasonable I'll open one or
> more
> > JIRAs and rebase the changes to trunk.
> >
> > Thanks!
> > Scott
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure

[Chris Hostetter]

: >Everything else... well, I don't understand why it does so much, let's
: >leave it at that :)
: 
: I think it does that to get the changes since last build. No idea what 
: rev-parseand rev-list do, this is the git hell and there is no escape. 

it's general jenkins plumbing that can serve various configuration 
options / trigger conditions ... 

the rev-parse lines are to figure out what commit SHA to associate with 
this build (in a way that also works with paramaterized build that takes 
in tag names or shorthand partial SHAs), so it can know if the current 
commit on the specified branch is diff from the last build (some people 
have time based triggers that only build if there is new revisions on the 
branch).  It checks this twice with two diff branches (just in case you 
forgot to start your branch spec with "origin".

the rev-list lines are for getting the list of changes for this build 
(allthough it admitedly seems really scary that cmmand doesn't 
specify two SHAs and/or include a --max-count param ... i guess jenkins 
assumes you'll never have billions of commits in your git rep)




: 
: Uwe
: 
: >D.
: >
: >
: >On Wed, Feb 17, 2016 at 10:05 PM, Uwe Schindler 
: >wrote:
: >> That's what it does with that option on ASF:
: >>
: >> Started by upstream project "Lucene-Solr-NightlyTests-5.x" build
: >number 1100
: >> originally caused by:
: >> Started by timer
: >> [EnvInject] - Loading node environment variables.
: >> Building remotely on lucene in workspace
: >> /home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x
: >>> git rev-parse --is-inside-work-tree # timeout=10
: >> Fetching changes from the remote Git repository
: >>> git config remote.origin.url git://git.apache.org/lucene-solr.git #
: >>> timeout=10
: >> Cleaning workspace
: >>> git rev-parse --verify HEAD # timeout=10
: >> Resetting working tree
: >>> git reset --hard # timeout=10
: >>> git clean -fdx # timeout=10
: >> Fetching upstream changes from git://git.apache.org/lucene-solr.git
: >>> git --version # timeout=10
: >>> git -c core.askpass=true fetch --tags --progress
: >>> git://git.apache.org/lucene-solr.git
: >+refs/heads/*:refs/remotes/origin/*
: >>> git rev-parse refs/remotes/origin/branch_5x^{commit} # timeout=10
: >>> git rev-parse refs/remotes/origin/origin/branch_5x^{commit} #
: >timeout=10
: >> Checking out Revision 56d426f814c090443b20e90f81969f5c060ca490
: >> (refs/remotes/origin/branch_5x)
: >>> git config core.sparsecheckout # timeout=10
: >>> git checkout -f 56d426f814c090443b20e90f81969f5c060ca490
: >>> git rev-list 56d426f814c090443b20e90f81969f5c060ca490 # timeout=10
: >> No emails were triggered.
: >> [lucene] $
: >>
: 
>/home/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ant-1.8.2/bin/ant
: >> -file build.xml -Dversion.suffix=1090 prepare-release-no-sign
: >>
: >> This is so horrible that I don't want to see it. :)
: >>
: >> I use my local git only with a GUI, that's fine to me.
: >>
: >> The issue here was just a misunderstanding, wrong terms used by
: >non-git
: >> fanatic people. To me a reset of working copy is what I want to have.
: >If
: >> that's a git clean with crazy parameters I don't care. It should just
: >reset
: >> to what I expect from the term 'reset'.
: >>
: >> Uwe
: >>
: >> Am 17. Februar 2016 21:56:23 MEZ, schrieb Dawid Weiss
: >> :
: 
:   This is how it looks like (attached screenshot). This option was
:  missing.
:   Now all is fine.
:   No need to discuss about git commands!
: >>>
: >>>
: >>> Fine, Uwe -- I was just mislead by your comment concerning "git
: >>> reset", that's all. The Jenkins option has nothing to do with git
: >>> reset, it very likely wipes the entire build folder and either
: >clones
: >>> from the remote anew or (smarter) clones from another local clone of
: >>> that remote repository.
: >>>
: >>> I admit there's something I don't understand in your heated replies
: >--
: >>> you always want to understand every detail of Java code yet you're
: >so
: >>> openly against trying to understand anything git-related. Why? It's
: >>> interesting, why resist it with such ferocity?
: >>>
: >>> Dawid
: >>>
: >>> P.S. For example, there is a huge performance difference between
: >>> what
: >>> Jenkins (above) probably does and my two git commands that result in
: >>> exactly the same output, but I'll leave the explanation since you
: >>> probably won't be interested anyway :)
: >>>
: >>> 
: >>>
: >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
: >>> For additional commands, e-mail: dev-h...@lucene.apache.org
: >>>
: >>
: >> --
: >> Uwe Schindler
: >> H.-H.-Meier-Allee 63, 28213 Bremen
: >> http://www.thetaphi.de
: >
: >-
: >To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
: >For additional commands, e-mail: dev-h...@lucene.apache.org
: 
: --
: Uwe Schindler
: H.-H.-Meier-Allee 

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 3092 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/3092/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample

Error Message:
Could not find a healthy node to handle the request.

Stack Trace:
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request.
at 
__randomizedtesting.SeedInfo.seed([42D092F8EB8D53B4:99A17232DCF896D2]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1084)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample(TestSolrCLIRunExample.java:446)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3977 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3977/

1 tests failed.
FAILED:  org.apache.solr.index.hdfs.CheckHdfsIndexTest.doTest

Error Message:
Could not find a healthy node to handle the request.

Stack Trace:
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request.
at 
__randomizedtesting.SeedInfo.seed([CAAC093D1DD1A44:ABEE7837BC6609FD]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1084)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:482)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1504)
at 
org.apache.solr.index.hdfs.CheckHdfsIndexTest.doTest(CheckHdfsIndexTest.java:100)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure

[Uwe Schindler]

Am 17. Februar 2016 22:08:58 MEZ, schrieb Dawid Weiss :
>Ah... so the clean option is actually smarter than I thought -- it
>does exactly what I said!
>
>Resetting working tree
>> git reset --hard # timeout=10
>> git clean -fdx # timeout=10

As you see first line contains 'reset', and this is why I wrote 'git reset' in 
my mail. When checking the earlier build logs I was missing this line. And then 
repaired config!

>Everything else... well, I don't understand why it does so much, let's
>leave it at that :)

I think it does that to get the changes since last build. No idea what 
rev-parseand rev-list do, this is the git hell and there is no escape. :')

Uwe

>D.
>
>
>On Wed, Feb 17, 2016 at 10:05 PM, Uwe Schindler 
>wrote:
>> That's what it does with that option on ASF:
>>
>> Started by upstream project "Lucene-Solr-NightlyTests-5.x" build
>number 1100
>> originally caused by:
>> Started by timer
>> [EnvInject] - Loading node environment variables.
>> Building remotely on lucene in workspace
>> /home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x
>>> git rev-parse --is-inside-work-tree # timeout=10
>> Fetching changes from the remote Git repository
>>> git config remote.origin.url git://git.apache.org/lucene-solr.git #
>>> timeout=10
>> Cleaning workspace
>>> git rev-parse --verify HEAD # timeout=10
>> Resetting working tree
>>> git reset --hard # timeout=10
>>> git clean -fdx # timeout=10
>> Fetching upstream changes from git://git.apache.org/lucene-solr.git
>>> git --version # timeout=10
>>> git -c core.askpass=true fetch --tags --progress
>>> git://git.apache.org/lucene-solr.git
>+refs/heads/*:refs/remotes/origin/*
>>> git rev-parse refs/remotes/origin/branch_5x^{commit} # timeout=10
>>> git rev-parse refs/remotes/origin/origin/branch_5x^{commit} #
>timeout=10
>> Checking out Revision 56d426f814c090443b20e90f81969f5c060ca490
>> (refs/remotes/origin/branch_5x)
>>> git config core.sparsecheckout # timeout=10
>>> git checkout -f 56d426f814c090443b20e90f81969f5c060ca490
>>> git rev-list 56d426f814c090443b20e90f81969f5c060ca490 # timeout=10
>> No emails were triggered.
>> [lucene] $
>>
>/home/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ant-1.8.2/bin/ant
>> -file build.xml -Dversion.suffix=1090 prepare-release-no-sign
>>
>> This is so horrible that I don't want to see it. :)
>>
>> I use my local git only with a GUI, that's fine to me.
>>
>> The issue here was just a misunderstanding, wrong terms used by
>non-git
>> fanatic people. To me a reset of working copy is what I want to have.
>If
>> that's a git clean with crazy parameters I don't care. It should just
>reset
>> to what I expect from the term 'reset'.
>>
>> Uwe
>>
>> Am 17. Februar 2016 21:56:23 MEZ, schrieb Dawid Weiss
>> :

  This is how it looks like (attached screenshot). This option was
 missing.
  Now all is fine.
  No need to discuss about git commands!
>>>
>>>
>>> Fine, Uwe -- I was just mislead by your comment concerning "git
>>> reset", that's all. The Jenkins option has nothing to do with git
>>> reset, it very likely wipes the entire build folder and either
>clones
>>> from the remote anew or (smarter) clones from another local clone of
>>> that remote repository.
>>>
>>> I admit there's something I don't understand in your heated replies
>--
>>> you always want to understand every detail of Java code yet you're
>so
>>> openly against trying to understand anything git-related. Why? It's
>>> interesting, why resist it with such ferocity?
>>>
>>> Dawid
>>>
>>> P.S. For example, there is a huge performance difference between
>>> what
>>> Jenkins (above) probably does and my two git commands that result in
>>> exactly the same output, but I'll leave the explanation since you
>>> probably won't be interested anyway :)
>>>
>>> 
>>>
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>> --
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, 28213 Bremen
>> http://www.thetaphi.de
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>For additional commands, e-mail: dev-h...@lucene.apache.org

--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de

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

[jira] [Updated] (SOLR-8349) Allow sharing of large in memory data structures across cores

[Gus Heck (JIRA)]

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

Gus Heck updated SOLR-8349:
---
Attachment: SOLR-8349.patch

Changes since original patch:
# No interface added to lucene, and no support for lucene analyzers to use this 
feature at this time. (defer to subsequent enhancement)
# Caching now done using a Guava cache. This simplifies code, but means that a 
core loading a given resource will now block the loading of other cores that 
also require that resource.
# As suggested by Dave, the cache now uses weak references to the values 
avoiding the possibility of a ClassLoader memory leak. The SolrCore object now 
gets a hard reference to the object. This means that there is now some chance 
that a resource will be unloaded if the last core using it is unloaded and then 
loaded again. This differs from the previous code where it was guaranteed to 
not be unloaded. To guarantee an deterministic behavior we likely would need to 
use hard references in the cache as before, or add something along the lines of 
a reference counting scheme to know when the last core stopped using it.
# To ensure that the SolrCore is given a reference to the loaded object, a 
ContainerResourceAware interface was added and is treated similarly to 
SolrCoreAware and ResourceLoaderAware. This allows components to give us the 
loading code before we give them the core, and thus we can coordinate the 
loading such that no there is always a hard reference to the resource (until 
the last core using it is unloaded). 

> Allow sharing of large in memory data structures across cores
> -
>
> Key: SOLR-8349
> URL: https://issues.apache.org/jira/browse/SOLR-8349
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.3
>Reporter: Gus Heck
> Attachments: SOLR-8349.patch, SOLR-8349.patch
>
>
> In some cases search components or analysis classes may utilize a large 
> dictionary or other in-memory structure. When multiple cores are loaded with 
> identical configurations utilizing this large in memory structure, each core 
> holds it's own copy in memory. This has been noted in the past and a specific 
> case reported in SOLR-3443. This patch provides a generalized capability, and 
> if accepted, this capability will then be used to fix SOLR-3443.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure

[Dawid Weiss]

Ah... so the clean option is actually smarter than I thought -- it
does exactly what I said!

Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10

Everything else... well, I don't understand why it does so much, let's
leave it at that :)

D.


On Wed, Feb 17, 2016 at 10:05 PM, Uwe Schindler  wrote:
> That's what it does with that option on ASF:
>
> Started by upstream project "Lucene-Solr-NightlyTests-5.x" build number 1100
> originally caused by:
> Started by timer
> [EnvInject] - Loading node environment variables.
> Building remotely on lucene in workspace
> /home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x
>> git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>> git config remote.origin.url git://git.apache.org/lucene-solr.git #
>> timeout=10
> Cleaning workspace
>> git rev-parse --verify HEAD # timeout=10
> Resetting working tree
>> git reset --hard # timeout=10
>> git clean -fdx # timeout=10
> Fetching upstream changes from git://git.apache.org/lucene-solr.git
>> git --version # timeout=10
>> git -c core.askpass=true fetch --tags --progress
>> git://git.apache.org/lucene-solr.git +refs/heads/*:refs/remotes/origin/*
>> git rev-parse refs/remotes/origin/branch_5x^{commit} # timeout=10
>> git rev-parse refs/remotes/origin/origin/branch_5x^{commit} # timeout=10
> Checking out Revision 56d426f814c090443b20e90f81969f5c060ca490
> (refs/remotes/origin/branch_5x)
>> git config core.sparsecheckout # timeout=10
>> git checkout -f 56d426f814c090443b20e90f81969f5c060ca490
>> git rev-list 56d426f814c090443b20e90f81969f5c060ca490 # timeout=10
> No emails were triggered.
> [lucene] $
> /home/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ant-1.8.2/bin/ant
> -file build.xml -Dversion.suffix=1090 prepare-release-no-sign
>
> This is so horrible that I don't want to see it. :)
>
> I use my local git only with a GUI, that's fine to me.
>
> The issue here was just a misunderstanding, wrong terms used by non-git
> fanatic people. To me a reset of working copy is what I want to have. If
> that's a git clean with crazy parameters I don't care. It should just reset
> to what I expect from the term 'reset'.
>
> Uwe
>
> Am 17. Februar 2016 21:56:23 MEZ, schrieb Dawid Weiss
> :
>>>
>>>  This is how it looks like (attached screenshot). This option was
>>> missing.
>>>  Now all is fine.
>>>  No need to discuss about git commands!
>>
>>
>> Fine, Uwe -- I was just mislead by your comment concerning "git
>> reset", that's all. The Jenkins option has nothing to do with git
>> reset, it very likely wipes the entire build folder and either clones
>> from the remote anew or (smarter) clones from another local clone of
>> that remote repository.
>>
>> I admit there's something I don't understand in your heated replies --
>> you always want to understand every detail of Java code yet you're so
>> openly against trying to understand anything git-related. Why? It's
>> interesting, why resist it with such ferocity?
>>
>> Dawid
>>
>> P.S. For example, there is a huge performance difference between
>> what
>> Jenkins (above) probably does and my two git commands that result in
>> exactly the same output, but I'll leave the explanation since you
>> probably won't be interested anyway :)
>>
>> 
>>
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
> --
> Uwe Schindler
> H.-H.-Meier-Allee 63, 28213 Bremen
> http://www.thetaphi.de

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

Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure

[Uwe Schindler]

That's what it does with that option on ASF:

Started by upstream project "Lucene-Solr-NightlyTests-5.x" build number 1100
originally caused by:
 Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on lucene in workspace 
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > git://git.apache.org/lucene-solr.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_5x^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_5x^{commit} # timeout=10
Checking out Revision 56d426f814c090443b20e90f81969f5c060ca490 
(refs/remotes/origin/branch_5x)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 56d426f814c090443b20e90f81969f5c060ca490
 > git rev-list 56d426f814c090443b20e90f81969f5c060ca490 # timeout=10
No emails were triggered.
[lucene] $ 
/home/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ant-1.8.2/bin/ant
 -file build.xml -Dversion.suffix=1090 prepare-release-no-sign

This is so horrible that I don't want to see it. :)

I use my local git only with a GUI, that's fine to me.

The issue here was just a misunderstanding, wrong terms used by non-git fanatic 
people. To me a reset of working copy is what I want to have. If that's a git 
clean with crazy parameters I don't care. It should just reset to what I expect 
from the term 'reset'.

Uwe

Am 17. Februar 2016 21:56:23 MEZ, schrieb Dawid Weiss :
>> This is how it looks like (attached screenshot). This option was
>missing.
>> Now all is fine.
>> No need to discuss about git commands!
>
>Fine, Uwe -- I was just mislead by your comment concerning "git
>reset", that's all. The Jenkins option has nothing to do with git
>reset, it very likely wipes the entire build folder and either clones
>from the remote anew or (smarter) clones from another local clone of
>that remote repository.
>
>I admit there's something I don't understand in your heated replies --
>you always want to understand every detail of Java code yet you're so
>openly against trying to understand anything git-related. Why? It's
>interesting, why resist it with such ferocity?
>
>Dawid
>
>P.S. For example, there is a huge performance difference between what
>Jenkins (above) probably does and my two git commands that result in
>exactly the same output, but I'll leave the explanation since you
>probably won't be interested anyway :)
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>For additional commands, e-mail: dev-h...@lucene.apache.org

--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de

[jira] [Commented] (SOLR-7708) Solr start/stop script is currently incompatible with Solaris (version 10)

[Charlie Hubbard (JIRA)]

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

Charlie Hubbard commented on SOLR-7708:
---

So I tried to port the existing script from Linux to Solaris and it's not going 
to work.  Mostly it comes down to 2 problems: ps and lsof.  On Solaris the 
default version of ps doesn't understand ps auxww.  The command line options 
aren't the same.  You can try and work around it by using ps from /usr/ucb, but 
ultimately trying to parse the out the command line arguments is the problem.  
On Solaris command line arguments are limited to 80 chars.  On linux command 
line is not truncated.  Solaris is 80 chars and that's it.  So a lot of the 
logic trying to parse things from the command line arguments is just NOT going 
to work.

Add to that lsof arguments aren't supported either, and lsof requires root 
privileges it becomes a loosing battle.  At this point I'm rewriting my own 
script that does simple things start/stop/restart.  The rest I really don't 
need.

> Solr start/stop script is currently incompatible with Solaris (version 10)
> --
>
> Key: SOLR-7708
> URL: https://issues.apache.org/jira/browse/SOLR-7708
> Project: Solr
>  Issue Type: Wish
>Affects Versions: 5.0, 5.1, 5.2, 5.2.1
> Environment: Solaris 10
>Reporter: Bence Vass
>
> Solr start/stop script is currently incompatible with Solaris (version 10)
> Main problems are:
> - use of lsof
> - options used on the ps command



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure

[Dawid Weiss]

> This is how it looks like (attached screenshot). This option was missing.
> Now all is fine.
> No need to discuss about git commands!

Fine, Uwe -- I was just mislead by your comment concerning "git
reset", that's all. The Jenkins option has nothing to do with git
reset, it very likely wipes the entire build folder and either clones
from the remote anew or (smarter) clones from another local clone of
that remote repository.

I admit there's something I don't understand in your heated replies --
you always want to understand every detail of Java code yet you're so
openly against trying to understand anything git-related. Why? It's
interesting, why resist it with such ferocity?

Dawid

P.S. For example, there is a huge performance difference between what
Jenkins (above) probably does and my two git commands that result in
exactly the same output, but I'll leave the explanation since you
probably won't be interested anyway :)

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

[jira] [Comment Edited] (SOLR-7555) Display total space and available space in Admin

[Jack Krupansky (JIRA)]

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

Jack Krupansky edited comment on SOLR-7555 at 2/17/16 8:52 PM:
---

I recently noticed that quite a few of the Amazon EC2 instance types have two 
or more local SSD storage devices. Should Solr display "total space" across all 
available local devices or just for the storage device on which Solr appears to 
be configured? If the instance supports EBS-only, I presume it would be total 
for EBS that the instance type supports.


was (Author: jkrupan):
I recently noticed that quite a few f the Amazon EC2 instance types have two or 
more local SSD storage devices. Should Solr display "total space" across all 
available local devices or just for the storage device on which Solr appears to 
be configured? If the instance supports EBS-only, I presume it would be total 
for EBS that the instance type supports.

> Display total space and available space in Admin
> 
>
> Key: SOLR-7555
> URL: https://issues.apache.org/jira/browse/SOLR-7555
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 5.1
>Reporter: Eric Pugh
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 6.0
>
> Attachments: DiskSpaceAwareDirectory.java, 
> SOLR-7555-display_disk_space.patch, SOLR-7555-display_disk_space_v2.patch, 
> SOLR-7555-display_disk_space_v3.patch, SOLR-7555-display_disk_space_v4.patch, 
> SOLR-7555-display_disk_space_v5.patch, SOLR-7555.patch, SOLR-7555.patch, 
> SOLR-7555.patch
>
>
> Frequently I have access to the Solr Admin console, but not the underlying 
> server, and I'm curious how much space remains available.   This little patch 
> exposes total Volume size as well as the usable space remaining:
> !https://monosnap.com/file/VqlReekCFwpK6utI3lP18fbPqrGI4b.png!
> I'm not sure if this is the best place to put this, as every shard will share 
> the same data, so maybe it should be on the top level Dashboard?  Also not 
> sure what to call the fields! 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7555) Display total space and available space in Admin

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-7555:
--

I recently noticed that quite a few f the Amazon EC2 instance types have two or 
more local SSD storage devices. Should Solr display "total space" across all 
available local devices or just for the storage device on which Solr appears to 
be configured? If the instance supports EBS-only, I presume it would be total 
for EBS that the instance type supports.

> Display total space and available space in Admin
> 
>
> Key: SOLR-7555
> URL: https://issues.apache.org/jira/browse/SOLR-7555
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 5.1
>Reporter: Eric Pugh
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 6.0
>
> Attachments: DiskSpaceAwareDirectory.java, 
> SOLR-7555-display_disk_space.patch, SOLR-7555-display_disk_space_v2.patch, 
> SOLR-7555-display_disk_space_v3.patch, SOLR-7555-display_disk_space_v4.patch, 
> SOLR-7555-display_disk_space_v5.patch, SOLR-7555.patch, SOLR-7555.patch, 
> SOLR-7555.patch
>
>
> Frequently I have access to the Solr Admin console, but not the underlying 
> server, and I'm curious how much space remains available.   This little patch 
> exposes total Volume size as well as the usable space remaining:
> !https://monosnap.com/file/VqlReekCFwpK6utI3lP18fbPqrGI4b.png!
> I'm not sure if this is the best place to put this, as every shard will share 
> the same data, so maybe it should be on the top level Dashboard?  Also not 
> sure what to call the fields! 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure

[Dawid Weiss]

> No nitpicking, please. I just wrote that it resets checkout to pristine
> state.

I wasn't trying? git reset won't delete any ignored files (like the
build/ folder) -- so either we differ in what a "pristine" state is or
you have a wrong understanding of git reset.

Try it on your local checkout after you've built Lucene or something:

git reset

The build folder will still be there.

D.

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

Re: [VOTE] Release Lucene/Solr 5.5.0 RC3

[Shalin Shekhar Mangar]

+1

SUCCESS! [1:07:58.838693]

On Tue, Feb 16, 2016 at 1:07 PM, Michael McCandless
 wrote:
> Please vote for the RC3 release candidate for Lucene/Solr 5.5.0, the
> last feature release before Lucene 6.0.0 and the first Lucene/Solr
> release since we switched from Subversion to git!
>
> Artifacts:
>
>   
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.0-RC3-rev2a228b3920a07f930f7afb6a42d0d20e184a943c
>
> Smoke tester:
>
>   python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.0-RC3-rev2a228b3920a07f930f7afb6a42d0d20e184a943c
>
> Please remember a release is not the time to shove last minute changes
> in.  Instead, shove those changes in immediately after the release so
> CI has plenty of time to chew on them.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



-- 
Regards,
Shalin Shekhar Mangar.

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

[jira] [Commented] (SOLR-8110) Start enforcing field naming recomendations in next X.0 release?

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-8110:
--

It would be nice to say that a "Solr identifier" had the same rules as a Java 
identifier, but Java allows dollar signs and excludes keywords and reserved 
terms like if, for, true, false, null. Hmmm... I don't know if many people 
would complain is Solr didn't allow those keywords as field names.

The main three exceptions to the current soft-rule that I have run across are:

1. Dot for compound names.
2. Hyphen feels a little more natural than underscore unless you're truly 
thinking about Java code and imagining that you could write a minus sign for a 
subtraction operation.
3. An ISO date/time value for dynamic fields which want to be time stamped. An 
optional text keyword prefix and hyphen are common for these timestamped 
columns as well.
4. Spaces, but I think sensible people can accept those as not permitted in 
names.

The main difficulty I am aware of in Solr is parsing of function queries, 
including (or especially) in the field list of the fl parameter.


> Start enforcing field naming recomendations in next X.0 release?
> 
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>
> For a very long time now, Solr has made the following "recommendation" 
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only 
> and not start with a digit.  This is not currently strictly enforced, but 
> other field names will not have first class support from all components and 
> back compatibility is not guaranteed.  ...
> I'm opening this issue to track discussion about if/how we should start 
> enforcing this as a rule instead (instead of just a "recommendation") in our 
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with 
> lists of field and produce strange errors when the huerstic fails (example: 
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the 
> recommended conventions and then only later encountering a situation where 
> their field names are not supported by some feature and get frustrated 
> because they have to change their schema, reindex, update index/query client 
> expectations, etc...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure

[Uwe Schindler]

No nitpicking, please. I just wrote that it resets checkout to pristine state. 
In fact the option in Jenkins does what it should. We don't need to discuss 
what it does behind scenes. I don't care about Gits horrible command line. :)

In fact Policeman uses Eclipse JGit to do the same. You don't see any command 
line in log outputs - that's the best to me. ASF Jenkins prints tons of 
gitshit, just look into logs! :)

Uwe

Am 17. Februar 2016 20:59:25 MEZ, schrieb Dawid Weiss :
>> I will check the Jenkins Config of this Job, maybe it is missing the
>extra GIT checkout option ("git reset").
>
>git reset actually only resets the tracked files that differ from the
>head. What you're looking for is two things:
>
># resets any staged changes (not that there should be any on jenkins,
>but for local repos there may be)
>git reset --hard
># clean ANY files not tracked in the repo -- this effectively restores
>pristine state.
>git clean -xfd .
>
>Dawid
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>For additional commands, e-mail: dev-h...@lucene.apache.org

--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de

[jira] [Created] (SOLR-8688) Concurrent[LRU|LFU]Cache should clear() upon destroy() to reduce GC stress

[Steve Shabino (JIRA)]

Steve Shabino created SOLR-8688:
---

 Summary: Concurrent[LRU|LFU]Cache should clear() upon destroy() to 
reduce GC stress
 Key: SOLR-8688
 URL: https://issues.apache.org/jira/browse/SOLR-8688
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: master
Reporter: Steve Shabino
Priority: Minor


When a SolrIndexSearcher is close()'d, it calls close() on all of its caches. 
FastLRUCache and LFUCache then call Concurrent[LRU|LFU]Cache's destroy(). The 
destroy method stops the clean-up thread if present, but it does not evict all 
cache entries - no longer of any value to a destroyed cache. 

Because Concurrent[LRU|LFU]Cache has a finalize() method, it and all objects 
referenced by it, even indirectly, may not be GC'ed until the JVM performs a 
major GC and the finalization thread runs.

Calling clear() on the underlying ConcurrentHashMap after stopping the clean-up 
thread will free cache entries (Several gigs worth as we're currently 
configured in production) for GC, independent of the JVM's finalization process.

Alternatively, uses of the finalize() method could be replaced with a clean-up 
scheme which makes use of PhantomReferences. There are a few other uses of 
finalize() in Solr which also could benefit from this. An example project (that 
I've only perused briefly): https://github.com/claudemartin/java-cleanup

I would be happy to prepare patches for either of these schemes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7555) Display total space and available space in Admin

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-7555:
---
Fix Version/s: (was: 5.5)
   6.0

> Display total space and available space in Admin
> 
>
> Key: SOLR-7555
> URL: https://issues.apache.org/jira/browse/SOLR-7555
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 5.1
>Reporter: Eric Pugh
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 6.0
>
> Attachments: DiskSpaceAwareDirectory.java, 
> SOLR-7555-display_disk_space.patch, SOLR-7555-display_disk_space_v2.patch, 
> SOLR-7555-display_disk_space_v3.patch, SOLR-7555-display_disk_space_v4.patch, 
> SOLR-7555-display_disk_space_v5.patch, SOLR-7555.patch, SOLR-7555.patch, 
> SOLR-7555.patch
>
>
> Frequently I have access to the Solr Admin console, but not the underlying 
> server, and I'm curious how much space remains available.   This little patch 
> exposes total Volume size as well as the usable space remaining:
> !https://monosnap.com/file/VqlReekCFwpK6utI3lP18fbPqrGI4b.png!
> I'm not sure if this is the best place to put this, as every shard will share 
> the same data, so maybe it should be on the top level Dashboard?  Also not 
> sure what to call the fields! 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8035) Move solr/webapp to solr/server/solr-webapp

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-8035:
---
Fix Version/s: (was: 5.5)
   (was: master)
   6.0

> Move solr/webapp to solr/server/solr-webapp
> ---
>
> Key: SOLR-8035
> URL: https://issues.apache.org/jira/browse/SOLR-8035
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 6.0
>
> Attachments: SOLR-8035.patch
>
>
> Let's move solr/webapp *source* files to their final actual distro 
> destination.  This facilitates folks editing the UI in real-time (save 
> change, refresh in browser) rather than having to "stop, ant server, restart" 
> to see a change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: ZK related startup fixes -- pre-review requested?

[Shalin Shekhar Mangar]

Hi Scott,

Those all sound very important fixes. I skimmed the changes and they
all look good to me. I think the ZkController changes are
straightforward. The leader election changes should get some more eyes
(maybe Mark Miller can chime in) but please do open the jira issues
(preferably separate ones for easier review+commit).

Thanks!

On Mon, Feb 15, 2016 at 1:59 PM, Scott Blum  wrote:
> Hi folks (paticularly Erick and Shalin),
>
> Before I go through the cycle of creating JIRAs and requesting formal
> review, I wondered if I could get some feedback on some work I've been doing
> to allow SolrCloud to startup faster and more reliably.
>
> Problems:
>
> 1) Quickly restarting a node makes leader election unreliable; the existing
> ZK node hasn't yet disappeared and confuses the current logic.  I believe I
> have fixed this and simplified the logic.  This affects overseer election.
>
> 2) ZkController.publishAndWaitForDownStates() occurs before overseer
> election.  That means if there is currently no overseer, there is ironically
> no one to actually service the down state changes it's waiting on.  This
> particularly affects a single-node cluster such as you might run locally for
> development.
>
> 3) Audited our current implementations of process(WatchedEvent) for
> consistency and handling edge cases.
>
> 4) Simplified DistributedMap; there's a whole lot more API surface area and
> implementation machinery than we're using.
>
> Code is here: https://github.com/fullstorydev/lucene-solr/pull/1
> The individual commits might be informative.
>
> Would some some feedback, and if these seem reasonable I'll open one or more
> JIRAs and rebase the changes to trunk.
>
> Thanks!
> Scott



-- 
Regards,
Shalin Shekhar Mangar.

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

[JENKINS] Lucene-Solr-SmokeRelease-5.5 - Build # 6 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.5/6/

No tests ran.

Build Log:
[...truncated 39773 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.02 sec (8.6 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.5.0-src.tgz...
   [smoker] 28.7 MB in 0.05 sec (526.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.5.0.tgz...
   [smoker] 63.4 MB in 0.13 sec (488.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.5.0.zip...
   [smoker] 73.9 MB in 0.13 sec (551.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.5.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.5.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.5.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 220 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 220 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [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 (31.6 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-5.5.0-src.tgz...
   [smoker] 37.5 MB in 1.05 sec (35.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.5.0.tgz...
   [smoker] 130.4 MB in 4.64 sec (28.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.5.0.zip...
   [smoker] 138.3 MB in 4.74 sec (29.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-5.5.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-5.5.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.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-5.5/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 7 ...
   [smoker] test solr example w/ Java 7...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.0-java7/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 

[JENKINS-EA] Lucene-Solr-5.5-Linux (64bit/jdk-9-ea+105) - Build # 33 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/33/
Java: 64bit/jdk-9-ea+105 -XX:+UseCompressedOops -XX:+UseSerialGC 
-XX:-UseSuperWord

2 tests failed.
FAILED:  org.apache.lucene.util.automaton.TestAutomaton.testRandomFinite

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([E25DAD69056BA5CF:A5EBCB54BAFBC0EE]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.lucene.util.automaton.TestAutomaton.assertSame(TestAutomaton.java:1120)
at 
org.apache.lucene.util.automaton.TestAutomaton.testRandomFinite(TestAutomaton.java:1034)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:804)


FAILED:  
org.apache.lucene.util.automaton.TestAutomaton.testMakeBinaryIntervalFiniteCasesRandom

Error Message:
automaton was not minimal

Stack Trace:
java.lang.AssertionError: automaton was not minimal
at 
__randomizedtesting.SeedInfo.seed([E25DAD69056BA5CF:9A5CBD91A6839B9E]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.lucene.util.automaton.TestAutomaton.makeBinaryInterval(TestAutomaton.java:1170)
at 

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+105) - Build # 15914 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15914/
Java: 32bit/jdk-9-ea+105 -server -XX:+UseConcMarkSweepGC -XX:-UseSuperWord

1 tests failed.
FAILED:  org.apache.solr.update.DirectUpdateHandlerTest.testExpungeDeletes

Error Message:
expected:<5> but was:<4>

Stack Trace:
java.lang.AssertionError: expected:<5> but was:<4>
at 
__randomizedtesting.SeedInfo.seed([5F02B6B0E5BF49C5:737BF23590068160]: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.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.update.DirectUpdateHandlerTest.testExpungeDeletes(DirectUpdateHandlerTest.java:299)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:804)




Build Log:
[...truncated 10818 lines...]
   [junit4] Suite: 

[jira] [Updated] (SOLR-8687) Race condition with RTGs during soft commit

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-8687:
---
Description: 
I am facing a problem with stress testing SOLR-5944, even though I think this 
problem persists in Solr even without my changes.

The symptom is that during a stress test (similar to TestStressReorder), RTG 
gets a document which is older version than that of the last acknowledged write.

Possible reason:
{code}
(DUH2's commit())
...
1:  if (cmd.softCommit) {
2:// ulog.preSoftCommit();
3:synchronized (solrCoreState.getUpdateLock()) {
4:  if (ulog != null) ulog.preSoftCommit(cmd);
5:  core.getSearcher(true, false, waitSearcher, true);
6:  if (ulog != null) ulog.postSoftCommit(cmd);
7:}
8:callPostSoftCommitCallbacks();
9:  }
...
{code}


* Before line 1, there was an update (say id=2) which was in ulog's map. Maps 
are, say, map=\{2=LogPtr(1234)\} , prevMap=\{...\} , prevMap2=\{...\}
* Due to line 4 (ulog.preSoftCommit()), the maps were rotated. Now, the id=2 is 
in prevMap: map={}, prevMap=\{2=LogPtr(1234)\}, prevMap2=\{...\} . Till now RTG 
for id=2 will work.
* Due to line 5, a new searcher is due to be opened. But this is asynchronous, 
and lets assume this doesn't complete before few more lines are executed.
* Due to line 6 (ulog.postSoftCommit()), the previous maps are cleared out. Now 
the maps are: map={}, prevMap=null, prevMap2=null
* If there's an RTG for id=2, it will not work from the ulog's maps, so it will 
fall through to be searched using the last searcher. But, the searcher due to 
be opened in line 5 hasn't yet been opened. In this case, the returned document 
will be whatever version of id=2 that was present in the previous searcher.

Can someone please confirm if this is a potential problem? If so, any 
suggestions for a fix, please? I tried opening a ulog.openRealtimeSearcher() in 
the above synchronized block, but the problem still persists, but I haven't 
looked into why that could be.

  was:
I am facing a problem with stress testing SOLR-5944, even though I think this 
problem persists in Solr even without my changes.

The symptom is that during a stress test (similar to TestStressReorder), RTG 
gets a document which is older version than that of the last acknowledged write.

Possible reason:
{code}
(DUH2's commit())
...
1:  if (cmd.softCommit) {
2:// ulog.preSoftCommit();
3:synchronized (solrCoreState.getUpdateLock()) {
4:  if (ulog != null) ulog.preSoftCommit(cmd);
5:  core.getSearcher(true, false, waitSearcher, true);
6:  if (ulog != null) ulog.postSoftCommit(cmd);
7:}
8:callPostSoftCommitCallbacks();
9:  }
...
{code}


* Before line 1, there was an update (say id=2) which was in ulog's map. Maps 
are, say, `map={2=LogPtr(1234)}, prevMap={...}, prevMap2={...}`
* Due to line 4 (ulog.preSoftCommit()), the maps were rotated. Now, the id=2 is 
in prevMap: `map={}, prevMap={2=LogPtr(1234)}, prevMap2={...}`. Till now RTG 
for id=2 will work.
* Due to line 5, a new searcher is due to be opened. But this is asynchronous, 
and lets assume this doesn't complete before few more lines are executed.
* Due to line 6 (ulog.postSoftCommit()), the previous maps are cleared out. Now 
the maps are: `map={}, prevMap=null, prevMap2=null`
* If there's an RTG for id=2, it will not work from the ulog's maps, so it will 
fall through to be searched using the last searcher. But, the searcher due to 
be opened in line 5 hasn't yet been opened. In this case, the returned document 
will be whatever version of id=2 that was present in the previous searcher.

Can someone please confirm if this is a potential problem? If so, any 
suggestions for a fix, please? I tried opening a ulog.openRealtimeSearcher() in 
the above synchronized block, but the problem still persists, but I haven't 
looked into why that could be.


> Race condition with RTGs during soft commit
> ---
>
> Key: SOLR-8687
> URL: https://issues.apache.org/jira/browse/SOLR-8687
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>
> I am facing a problem with stress testing SOLR-5944, even though I think this 
> problem persists in Solr even without my changes.
> The symptom is that during a stress test (similar to TestStressReorder), RTG 
> gets a document which is older version than that of the last acknowledged 
> write.
> Possible reason:
> {code}
> (DUH2's commit())
> ...
> 1:  if (cmd.softCommit) {
> 2:// ulog.preSoftCommit();
> 3:synchronized (solrCoreState.getUpdateLock()) {
> 4:  if (ulog != null) ulog.preSoftCommit(cmd);
> 5:  core.getSearcher(true, false, waitSearcher, true);
> 6:  if (ulog != null) ulog.postSoftCommit(cmd);
> 7:   

Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure

[Dawid Weiss]

> I will check the Jenkins Config of this Job, maybe it is missing the extra 
> GIT checkout option ("git reset").

git reset actually only resets the tracked files that differ from the
head. What you're looking for is two things:

# resets any staged changes (not that there should be any on jenkins,
but for local repos there may be)
git reset --hard
# clean ANY files not tracked in the repo -- this effectively restores
pristine state.
git clean -xfd .

Dawid

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

[jira] [Commented] (SOLR-8687) Race condition with RTGs during soft commit

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8687:


My stress test is here:
https://github.com/chatman/lucene-solr/blob/627b9ac9b46796f20be78b04ebbdfa4299b96ab7/solr/core/src/test/org/apache/solr/cloud/TestStressInPlaceUpdates.java

> Race condition with RTGs during soft commit
> ---
>
> Key: SOLR-8687
> URL: https://issues.apache.org/jira/browse/SOLR-8687
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>
> I am facing a problem with stress testing SOLR-5944, even though I think this 
> problem persists in Solr even without my changes.
> The symptom is that during a stress test (similar to TestStressReorder), RTG 
> gets a document which is older version than that of the last acknowledged 
> write.
> Possible reason:
> {code}
> (DUH2's commit())
> ...
> 1:  if (cmd.softCommit) {
> 2:// ulog.preSoftCommit();
> 3:synchronized (solrCoreState.getUpdateLock()) {
> 4:  if (ulog != null) ulog.preSoftCommit(cmd);
> 5:  core.getSearcher(true, false, waitSearcher, true);
> 6:  if (ulog != null) ulog.postSoftCommit(cmd);
> 7:}
> 8:callPostSoftCommitCallbacks();
> 9:  }
> ...
> {code}
> * Before line 1, there was an update (say id=2) which was in ulog's map. Maps 
> are, say, `map={2=LogPtr(1234)}, prevMap={...}, prevMap2={...}`
> * Due to line 4 (ulog.preSoftCommit()), the maps were rotated. Now, the id=2 
> is in prevMap: `map={}, prevMap={2=LogPtr(1234)}, prevMap2={...}`. Till now 
> RTG for id=2 will work.
> * Due to line 5, a new searcher is due to be opened. But this is 
> asynchronous, and lets assume this doesn't complete before few more lines are 
> executed.
> * Due to line 6 (ulog.postSoftCommit()), the previous maps are cleared out. 
> Now the maps are: `map={}, prevMap=null, prevMap2=null`
> * If there's an RTG for id=2, it will not work from the ulog's maps, so it 
> will fall through to be searched using the last searcher. But, the searcher 
> due to be opened in line 5 hasn't yet been opened. In this case, the returned 
> document will be whatever version of id=2 that was present in the previous 
> searcher.
> Can someone please confirm if this is a potential problem? If so, any 
> suggestions for a fix, please? I tried opening a ulog.openRealtimeSearcher() 
> in the above synchronized block, but the problem still persists, but I 
> haven't looked into why that could be.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-8687) Race condition with RTGs during soft commit

[Ishan Chattopadhyaya (JIRA)]

Ishan Chattopadhyaya created SOLR-8687:
--

 Summary: Race condition with RTGs during soft commit
 Key: SOLR-8687
 URL: https://issues.apache.org/jira/browse/SOLR-8687
 Project: Solr
  Issue Type: Bug
Reporter: Ishan Chattopadhyaya


I am facing a problem with stress testing SOLR-5944, even though I think this 
problem persists in Solr even without my changes.

The symptom is that during a stress test (similar to TestStressReorder), RTG 
gets a document which is older version than that of the last acknowledged write.

Possible reason:
{code}
(DUH2's commit())
...
1:  if (cmd.softCommit) {
2:// ulog.preSoftCommit();
3:synchronized (solrCoreState.getUpdateLock()) {
4:  if (ulog != null) ulog.preSoftCommit(cmd);
5:  core.getSearcher(true, false, waitSearcher, true);
6:  if (ulog != null) ulog.postSoftCommit(cmd);
7:}
8:callPostSoftCommitCallbacks();
9:  }
...
{code}


* Before line 1, there was an update (say id=2) which was in ulog's map. Maps 
are, say, `map={2=LogPtr(1234)}, prevMap={...}, prevMap2={...}`
* Due to line 4 (ulog.preSoftCommit()), the maps were rotated. Now, the id=2 is 
in prevMap: `map={}, prevMap={2=LogPtr(1234)}, prevMap2={...}`. Till now RTG 
for id=2 will work.
* Due to line 5, a new searcher is due to be opened. But this is asynchronous, 
and lets assume this doesn't complete before few more lines are executed.
* Due to line 6 (ulog.postSoftCommit()), the previous maps are cleared out. Now 
the maps are: `map={}, prevMap=null, prevMap2=null`
* If there's an RTG for id=2, it will not work from the ulog's maps, so it will 
fall through to be searched using the last searcher. But, the searcher due to 
be opened in line 5 hasn't yet been opened. In this case, the returned document 
will be whatever version of id=2 that was present in the previous searcher.

Can someone please confirm if this is a potential problem? If so, any 
suggestions for a fix, please? I tried opening a ulog.openRealtimeSearcher() in 
the above synchronized block, but the problem still persists, but I haven't 
looked into why that could be.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Race condition with RTGs during soft commit

[Ishan Chattopadhyaya]

JIRA is back up, and I filed SOLR-8687.
Thanks.

On Thu, Feb 18, 2016 at 1:19 AM, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> I am facing a problem with stress testing SOLR-5944, even though I think
> this problem persists in Solr even without my changes.
>
> The symptom is that during a stress test (similar to TestStressReorder),
> RTG gets a document which is older version than that of the last
> acknowledged write.
>
> Possible reason:
>
> ```(DUH2's commit())
> ...
> 1:  if (cmd.softCommit) {
> 2:// ulog.preSoftCommit();
> 3:synchronized (solrCoreState.getUpdateLock()) {
> 4:  if (ulog != null) ulog.preSoftCommit(cmd);
> 5:  core.getSearcher(true, false, waitSearcher, true);
> 6:  if (ulog != null) ulog.postSoftCommit(cmd);
> 7:}
> 8:callPostSoftCommitCallbacks();
> 9:  }
> ...
> ```
>
>
> * Before line 1, there was an update (say id=2) which was in ulog's map.
> Maps are, say, `map={2=LogPtr(1234)}, prevMap={...}, prevMap2={...}`
> * Due to line 4 (ulog.preSoftCommit()), the maps were rotated. Now, the
> id=2 is in prevMap: `map={}, prevMap={2=LogPtr(1234)}, prevMap2={...}`.
> Till now RTG for id=2 will work.
> * Due to line 5, a new searcher is due to be opened. But this is
> asynchronous, and lets assume this doesn't complete before few more lines
> are executed.
> * Due to line 6 (ulog.postSoftCommit()), the previous maps are cleared
> out. Now the maps are: `map={}, prevMap=null, prevMap2=null`
> * If there's an RTG for id=2, it will not work from the ulog's maps, so it
> will fall through to be searched using the last searcher. But, the searcher
> due to be opened in line 5 hasn't yet been opened. In this case, the
> returned document will be whatever version of id=2 that was present in the
> previous searcher.
>
> I cannot seem to access JIRA at the moment, so cannot file a bug right
> now. Can someone please confirm if this is a valid problem? If so, any
> suggestions for a fix, please? (I tried opening a
> ulog.openRealtimeSearcher() in the above synchronized block, but the
> problem still persists).
>

Race condition with RTGs during soft commit

[Ishan Chattopadhyaya]

I am facing a problem with stress testing SOLR-5944, even though I think
this problem persists in Solr even without my changes.

The symptom is that during a stress test (similar to TestStressReorder),
RTG gets a document which is older version than that of the last
acknowledged write.

Possible reason:

```(DUH2's commit())
...
1:  if (cmd.softCommit) {
2:// ulog.preSoftCommit();
3:synchronized (solrCoreState.getUpdateLock()) {
4:  if (ulog != null) ulog.preSoftCommit(cmd);
5:  core.getSearcher(true, false, waitSearcher, true);
6:  if (ulog != null) ulog.postSoftCommit(cmd);
7:}
8:callPostSoftCommitCallbacks();
9:  }
...
```


* Before line 1, there was an update (say id=2) which was in ulog's map.
Maps are, say, `map={2=LogPtr(1234)}, prevMap={...}, prevMap2={...}`
* Due to line 4 (ulog.preSoftCommit()), the maps were rotated. Now, the
id=2 is in prevMap: `map={}, prevMap={2=LogPtr(1234)}, prevMap2={...}`.
Till now RTG for id=2 will work.
* Due to line 5, a new searcher is due to be opened. But this is
asynchronous, and lets assume this doesn't complete before few more lines
are executed.
* Due to line 6 (ulog.postSoftCommit()), the previous maps are cleared out.
Now the maps are: `map={}, prevMap=null, prevMap2=null`
* If there's an RTG for id=2, it will not work from the ulog's maps, so it
will fall through to be searched using the last searcher. But, the searcher
due to be opened in line 5 hasn't yet been opened. In this case, the
returned document will be whatever version of id=2 that was present in the
previous searcher.

I cannot seem to access JIRA at the moment, so cannot file a bug right now.
Can someone please confirm if this is a valid problem? If so, any
suggestions for a fix, please? (I tried opening a
ulog.openRealtimeSearcher() in the above synchronized block, but the
problem still persists).

Re: [VOTE] Release Lucene/Solr 5.5.0 RC3

[Steve Rowe]

+1

Docs, changes and javadocs look good.

I ran the smoke tester with —test-java8: SUCCESS! [0:40:02.457972]

--
Steve
www.lucidworks.com

> On Feb 16, 2016, at 4:07 PM, Michael McCandless  
> wrote:
> 
> Please vote for the RC3 release candidate for Lucene/Solr 5.5.0, the
> last feature release before Lucene 6.0.0 and the first Lucene/Solr
> release since we switched from Subversion to git!
> 
> Artifacts:
> 
>  
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.0-RC3-rev2a228b3920a07f930f7afb6a42d0d20e184a943c
> 
> Smoke tester:
> 
>  python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.0-RC3-rev2a228b3920a07f930f7afb6a42d0d20e184a943c
> 
> Please remember a release is not the time to shove last minute changes
> in.  Instead, shove those changes in immediately after the release so
> CI has plenty of time to chew on them.
> 
> Mike McCandless
> 
> http://blog.mikemccandless.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

Re: [jira] [Commented] (SOLR-8110) Start enforcing field naming recomendations in next X.0 release?

[Erick Erickson]

IMO, simply having a standard at least gives us a standard and a reason to
fix the edge cases. As it stands now, there's no basis to even say
something should be fixed. So periods are fine as far as I'm concerned.
On Feb 17, 2016 10:49, "Shawn Heisey (JIRA)"  wrote:

>
> [
> https://issues.apache.org/jira/browse/SOLR-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15149605#comment-15149605
> ]
>
> Shawn Heisey commented on SOLR-8110:
> 
>
> With the caveat that I haven't actually tried it and haven't looked at
> code, I can't immediately think of any reason periods would cause any
> problems, at least not with the top three query parsers -- lucene, dismax,
> and edismax.
>
> > Start enforcing field naming recomendations in next X.0 release?
> > 
> >
> > Key: SOLR-8110
> > URL: https://issues.apache.org/jira/browse/SOLR-8110
> > Project: Solr
> >  Issue Type: Improvement
> >Reporter: Hoss Man
> >
> > For a very long time now, Solr has made the following "recommendation"
> regarding field naming conventions...
> > bq. field names should consist of alphanumeric or underscore characters
> only and not start with a digit.  This is not currently strictly enforced,
> but other field names will not have first class support from all components
> and back compatibility is not guaranteed.  ...
> > I'm opening this issue to track discussion about if/how we should start
> enforcing this as a rule instead (instead of just a "recommendation") in
> our next/future X.0 (ie: major) release.
> > The goals of doing so being:
> > * simplify some existing code/apis that currently use hueristics to deal
> with lists of field and produce strange errors when the huerstic fails
> (example: ReturnFields.add)
> > * reduce confusion/pain for new users who might start out unaware of the
> recommended conventions and then only later encountering a situation where
> their field names are not supported by some feature and get frustrated
> because they have to change their schema, reindex, update index/query
> client expectations, etc...
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[JENKINS-EA] Lucene-Solr-5.5-Linux (64bit/jdk-9-ea+105) - Build # 29 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/29/
Java: 64bit/jdk-9-ea+105 -XX:+UseCompressedOops -XX:+UseParallelGC 
-XX:-CompactStrings -XX:-UseSuperWord

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=6473, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)2) Thread[id=6474, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)3) Thread[id=6471, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)4) Thread[id=6475, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)5) Thread[id=6472, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=6473, name=ou=system.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at jdk.internal.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
at 

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk-9-ea+105) - Build # 15912 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15912/
Java: 64bit/jdk-9-ea+105 -XX:-UseCompressedOops -XX:+UseSerialGC 
-XX:-CompactStrings -XX:-UseSuperWord

3 tests failed.
FAILED:  org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat.testRandom

Error Message:
Captured an uncaught exception in thread: Thread[id=1956, name=Thread-1494, 
state=RUNNABLE, group=TGRP-TestBlockPostingsFormat]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=1956, name=Thread-1494, state=RUNNABLE, 
group=TGRP-TestBlockPostingsFormat]
Caused by: java.lang.RuntimeException: java.lang.IllegalArgumentException: 
source=3 is out of bounds (maxState is 2)
at __randomizedtesting.SeedInfo.seed([B2144C216CCF352D]:0)
at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1006)
Caused by: java.lang.IllegalArgumentException: source=3 is out of bounds 
(maxState is 2)
at 
org.apache.lucene.util.automaton.Automaton.addTransition(Automaton.java:165)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:245)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:537)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomSingleAutomaton(AutomatonTestUtil.java:262)
at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomAutomaton(AutomatonTestUtil.java:276)
at 
org.apache.lucene.index.RandomPostingsTester.testTermsOneThread(RandomPostingsTester.java:1167)
at 
org.apache.lucene.index.RandomPostingsTester.access$000(RandomPostingsTester.java:61)
at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1004)


FAILED:  
org.apache.lucene.util.automaton.FiniteStringsIteratorTest.testShortAccept

Error Message:
source=3 is out of bounds (maxState is 2)

Stack Trace:
java.lang.IllegalArgumentException: source=3 is out of bounds (maxState is 2)
at 
__randomizedtesting.SeedInfo.seed([B2144C216CCF352D:CF27BD26A38E0643]:0)
at 
org.apache.lucene.util.automaton.Automaton.addTransition(Automaton.java:165)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:245)
at 
org.apache.lucene.util.automaton.FiniteStringsIteratorTest.testShortAccept(FiniteStringsIteratorTest.java:158)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure

[Steve Rowe]

Aha, thanks for figuring the Jenkins thing out Uwe. 

--
Steve
www.lucidworks.com

> On Feb 17, 2016, at 1:25 PM, Uwe Schindler  wrote:
> 
> Hehe,
> 
> for this checkout the "Clean Before Checkout" option was missing in Jenkins 
> (5.x). Steve cloned this for 5.5, too. This is why every 2nd build fails.
> 
> I am clicking through Jenkins and checking all jobs. It is a pity that we 
> don't have the "mass change" plugin on ASF Jenkins to change the same option 
> for many Jobs.
> Uwe
> 
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> 
>> -Original Message-
>> From: Uwe Schindler [mailto:u...@thetaphi.de]
>> Sent: Wednesday, February 17, 2016 7:21 PM
>> To: dev@lucene.apache.org
>> Subject: RE: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure
>> 
>> But why does this fail on Jenkins? Jenkins starts with cleaned checkout
>> 
>> I will check the Jenkins Config of this Job, maybe it is missing the extra 
>> GIT
>> checkout option ("git reset").
>> 
>> Uwe
>> 
>> -
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: u...@thetaphi.de
>> 
>>> -Original Message-
>>> From: Dawid Weiss [mailto:dawid.we...@gmail.com]
>>> Sent: Wednesday, February 17, 2016 4:44 PM
>>> To: dev@lucene.apache.org
>>> Subject: Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure
>>> 
>>> This is actually very predictable -- if you run it once, it succeeds.
>>> If you re-run it then (without cleaning) it always fails, even with
>>> -v. I filed this and mention the problem's cause, but I won't have the
>>> time to fix it -- sorry!
>>> 
>>> https://issues.apache.org/jira/browse/LUCENE-7033
>>> 
>>> Dawid
>>> 
>>> On Tue, Feb 16, 2016 at 3:50 PM, Michael McCandless
>>>  wrote:
 OK I ran without -v, piping to a file, and it succeeds.
 
 Then I run straight to the console, without -v, and it fails.
 
 I'll see if I can get it to fail with -v...
 
 Mike McCandless
 
 http://blog.mikemccandless.com
 
 On Tue, Feb 16, 2016 at 5:26 AM, Dawid Weiss 
>>> wrote:
> Can you:
> 
> ant -v > output.log 2>&1
> 
> Perhaps it's a timing issue when -v is dumped to the console?
> 
> Dawid
> 
> 
> On Tue, Feb 16, 2016 at 10:59 AM, Michael McCandless
>  wrote:
>> I could still use some help on this one!
>> 
>> Somehow this succeeds when I run "ant -v" fails otherwise.
>> 
>> Mike McCandless
>> 
>> http://blog.mikemccandless.com
>> 
>> 
>> On Tue, Feb 16, 2016 at 1:32 AM, Apache Jenkins Server
>>  wrote:
>>> Build: https://builds.apache.org/job/Lucene-Artifacts-5.x/1088/
>>> 
>>> No tests ran.
>>> 
>>> Build Log:
>>> [...truncated 8805 lines...]
>>> BUILD FAILED
>>> /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
>>> 5.x/lucene/build.xml:427: The following error occurred while executing this
>>> line:
>>> /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
>>> 5.x/lucene/build.xml:415: The following error occurred while executing this
>>> line:
>>> /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
>>> 5.x/lucene/common-build.xml:1724: The following error occurred while
>>> executing this line:
>>> /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
>>> 5.x/lucene/common-build.xml:608: Error installing artifact
>>> 'org.apache.lucene:lucene-core:jar': Error installing artifact: File
>>> /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
>>> 5.x/lucene/build/lucene.tgz.unpacked/lucene-5.6.0-1088/core/lucene-
>> core-
>>> 5.6.0-1088.jar does not exist
>>> 
>>> Total time: 4 minutes 52 seconds
>>> Build step 'Invoke Ant' marked build as failure
>>> Archiving artifacts
>>> Compressed 167.65 MB of artifacts by 22.5% relative to #1087
>>> Publishing Javadoc
>>> Email was triggered for: Failure - Any
>>> Sending email for trigger: Failure - Any
>>> 
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
>> -
>> 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 

[JENKINS] Lucene-Solr-Tests-5.5-Java7 - Build # 10 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.5-Java7/10/

2 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

Error Message:
Test abandoned because suite timeout was reached.

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


FAILED:  
junit.framework.TestSuite.org.apache.solr.security.BasicAuthIntegrationTest

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

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




Build Log:
[...truncated 12507 lines...]
   [junit4] Suite: org.apache.solr.security.BasicAuthIntegrationTest
   [junit4]   2> 2020339 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[AC5FA4FC630F58DB]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 2020339 INFO  (Thread-7039) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 2020339 INFO  (Thread-7039) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 2020439 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[AC5FA4FC630F58DB]) [] 
o.a.s.c.ZkTestServer start zk server on port:58075
   [junit4]   2> 2020439 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[AC5FA4FC630F58DB]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 2020466 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[AC5FA4FC630F58DB]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 2020476 INFO  (zkCallback-2585-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@24342387 
name:ZooKeeperConnection Watcher:127.0.0.1:58075 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 2020477 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[AC5FA4FC630F58DB]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 2020477 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[AC5FA4FC630F58DB]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 2020477 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[AC5FA4FC630F58DB]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
   [junit4]   2> 2020522 INFO  (jetty-launcher-2584-thread-1) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 2020529 INFO  (jetty-launcher-2584-thread-1) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@1bf4eea9{/solr,null,AVAILABLE}
   [junit4]   2> 2020529 INFO  (jetty-launcher-2584-thread-3) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 2020529 INFO  (jetty-launcher-2584-thread-2) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 2020529 INFO  (jetty-launcher-2584-thread-1) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@52e6aa2d{HTTP/1.1}{127.0.0.1:50858}
   [junit4]   2> 2020530 INFO  (jetty-launcher-2584-thread-5) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 2020530 INFO  (jetty-launcher-2584-thread-1) [] 
o.e.j.s.Server Started @2023363ms
   [junit4]   2> 2020530 INFO  (jetty-launcher-2584-thread-1) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr, 
hostPort=50858}
   [junit4]   2> 2020530 INFO  (jetty-launcher-2584-thread-1) [] 
o.a.s.s.SolrDispatchFilter SolrDispatchFilter.init(): 
sun.misc.Launcher$AppClassLoader@41692a49
   [junit4]   2> 2020530 INFO  (jetty-launcher-2584-thread-1) [] 
o.a.s.c.SolrResourceLoader new SolrResourceLoader for directory: 
'/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5-Java7/solr/build/solr-core/test/J2/temp/solr.security.BasicAuthIntegrationTest_AC5FA4FC630F58DB-001/tempDir-001/node1'
   [junit4]   2> 2020530 INFO  (jetty-launcher-2584-thread-1) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 2020530 INFO  (jetty-launcher-2584-thread-1) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 2020531 INFO  (jetty-launcher-2584-thread-1) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 2020553 INFO  (jetty-launcher-2584-thread-5) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@7c9e01a0{/solr,null,AVAILABLE}
   [junit4]   2> 2020554 INFO  (jetty-launcher-2584-thread-1) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 2020590 INFO  (jetty-launcher-2584-thread-2) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@60e973d0{/solr,null,AVAILABLE}
   [junit4]   2> 2020590 INFO  (jetty-launcher-2584-thread-2) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@7eb28e64{HTTP/1.1}{127.0.0.1:54054}
   [junit4]   2> 2020591 INFO  

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Solaris/398/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.SyncSliceTest.test

Error Message:
expected:<5> but was:<4>

Stack Trace:
java.lang.AssertionError: expected:<5> but was:<4>
at 
__randomizedtesting.SeedInfo.seed([E9E3F56593F8E51C:61B7CABF3D0488E4]: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.junit.Assert.assertEquals(Assert.java:456)
at org.apache.solr.cloud.SyncSliceTest.test(SyncSliceTest.java:153)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

Re: [VOTE] Release Lucene/Solr 5.5.0 RC3

[Anshum Gupta]

+1

The Changes and Java docs look good too.

SUCCESS! [0:31:27.236805]

On Tue, Feb 16, 2016 at 1:07 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> Please vote for the RC3 release candidate for Lucene/Solr 5.5.0, the
> last feature release before Lucene 6.0.0 and the first Lucene/Solr
> release since we switched from Subversion to git!
>
> Artifacts:
>
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.0-RC3-rev2a228b3920a07f930f7afb6a42d0d20e184a943c
>
> Smoke tester:
>
>   python3 -u dev-tools/scripts/smokeTestRelease.py
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.0-RC3-rev2a228b3920a07f930f7afb6a42d0d20e184a943c
>
> Please remember a release is not the time to shove last minute changes
> in.  Instead, shove those changes in immediately after the release so
> CI has plenty of time to chew on them.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Anshum Gupta

[JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk-9-ea+105) - Build # 15600 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15600/
Java: 64bit/jdk-9-ea+105 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 
-XX:-CompactStrings -XX:-UseSuperWord

3 tests failed.
FAILED:  org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3.test

Error Message:
9

Stack Trace:
java.lang.ArrayIndexOutOfBoundsException: 9
at 
__randomizedtesting.SeedInfo.seed([700097738256FA74:F854A8A92CAA978C]:0)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:524)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
at 
org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3.assertTerms(TestBlockPostingsFormat3.java:186)
at 
org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3.verify(TestBlockPostingsFormat3.java:153)
at 
org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3.test(TestBlockPostingsFormat3.java:137)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:804)


FAILED:  org.apache.lucene.util.automaton.TestLevenshteinAutomata.testLev2

Error Message:


Stack Trace:
java.lang.AssertionError
at 

Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure

[Michael McCandless]

Whoa, thank you Dawid and Uwe for digging into this!!

Mike McCandless

http://blog.mikemccandless.com


On Wed, Feb 17, 2016 at 1:25 PM, Uwe Schindler  wrote:
> Hehe,
>
> for this checkout the "Clean Before Checkout" option was missing in Jenkins 
> (5.x). Steve cloned this for 5.5, too. This is why every 2nd build fails.
>
> I am clicking through Jenkins and checking all jobs. It is a pity that we 
> don't have the "mass change" plugin on ASF Jenkins to change the same option 
> for many Jobs.
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -Original Message-
>> From: Uwe Schindler [mailto:u...@thetaphi.de]
>> Sent: Wednesday, February 17, 2016 7:21 PM
>> To: dev@lucene.apache.org
>> Subject: RE: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure
>>
>> But why does this fail on Jenkins? Jenkins starts with cleaned checkout
>>
>> I will check the Jenkins Config of this Job, maybe it is missing the extra 
>> GIT
>> checkout option ("git reset").
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>> > -Original Message-
>> > From: Dawid Weiss [mailto:dawid.we...@gmail.com]
>> > Sent: Wednesday, February 17, 2016 4:44 PM
>> > To: dev@lucene.apache.org
>> > Subject: Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure
>> >
>> > This is actually very predictable -- if you run it once, it succeeds.
>> > If you re-run it then (without cleaning) it always fails, even with
>> > -v. I filed this and mention the problem's cause, but I won't have the
>> > time to fix it -- sorry!
>> >
>> > https://issues.apache.org/jira/browse/LUCENE-7033
>> >
>> > Dawid
>> >
>> > On Tue, Feb 16, 2016 at 3:50 PM, Michael McCandless
>> >  wrote:
>> > > OK I ran without -v, piping to a file, and it succeeds.
>> > >
>> > > Then I run straight to the console, without -v, and it fails.
>> > >
>> > > I'll see if I can get it to fail with -v...
>> > >
>> > > Mike McCandless
>> > >
>> > > http://blog.mikemccandless.com
>> > >
>> > > On Tue, Feb 16, 2016 at 5:26 AM, Dawid Weiss 
>> > wrote:
>> > >> Can you:
>> > >>
>> > >> ant -v > output.log 2>&1
>> > >>
>> > >> Perhaps it's a timing issue when -v is dumped to the console?
>> > >>
>> > >> Dawid
>> > >>
>> > >>
>> > >> On Tue, Feb 16, 2016 at 10:59 AM, Michael McCandless
>> > >>  wrote:
>> > >>> I could still use some help on this one!
>> > >>>
>> > >>> Somehow this succeeds when I run "ant -v" fails otherwise.
>> > >>>
>> > >>> Mike McCandless
>> > >>>
>> > >>> http://blog.mikemccandless.com
>> > >>>
>> > >>>
>> > >>> On Tue, Feb 16, 2016 at 1:32 AM, Apache Jenkins Server
>> > >>>  wrote:
>> >  Build: https://builds.apache.org/job/Lucene-Artifacts-5.x/1088/
>> > 
>> >  No tests ran.
>> > 
>> >  Build Log:
>> >  [...truncated 8805 lines...]
>> >  BUILD FAILED
>> >  /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
>> > 5.x/lucene/build.xml:427: The following error occurred while executing this
>> > line:
>> >  /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
>> > 5.x/lucene/build.xml:415: The following error occurred while executing this
>> > line:
>> >  /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
>> > 5.x/lucene/common-build.xml:1724: The following error occurred while
>> > executing this line:
>> >  /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
>> > 5.x/lucene/common-build.xml:608: Error installing artifact
>> > 'org.apache.lucene:lucene-core:jar': Error installing artifact: File
>> > /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
>> > 5.x/lucene/build/lucene.tgz.unpacked/lucene-5.6.0-1088/core/lucene-
>> core-
>> > 5.6.0-1088.jar does not exist
>> > 
>> >  Total time: 4 minutes 52 seconds
>> >  Build step 'Invoke Ant' marked build as failure
>> >  Archiving artifacts
>> >  Compressed 167.65 MB of artifacts by 22.5% relative to #1087
>> >  Publishing Javadoc
>> >  Email was triggered for: Failure - Any
>> >  Sending email for trigger: Failure - Any
>> > 
>> > 
>> > 
>> > 
>> >  -
>> >  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >  For additional commands, e-mail: dev-h...@lucene.apache.org
>> > >>>
>> > >>> -
>> > >>> 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
>> > >>
>> > >
>> > > 

Re: Playing with Java Object Alignment

[Dawid Weiss]

> For example -XX:ObjectAlignmentInBytes=16

Last time I did play with this (which was a good couple of years ago)
I could crash the JVM routinely by changing this value from the
default...

D.

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

[JENKINS] Lucene-Solr-trunk-Solaris (64bit/jdk1.8.0) - Build # 408 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/408/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.test

Error Message:
There are still nodes recoverying - waited for 45 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 45 
seconds
at 
__randomizedtesting.SeedInfo.seed([43F6DC65C75CC80D:CBA2E3BF69A0A5F5]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:174)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856)
at 
org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.test(DistribDocExpirationUpdateProcessorTest.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

RE: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure

[Uwe Schindler]

Hehe,

for this checkout the "Clean Before Checkout" option was missing in Jenkins 
(5.x). Steve cloned this for 5.5, too. This is why every 2nd build fails.

I am clicking through Jenkins and checking all jobs. It is a pity that we don't 
have the "mass change" plugin on ASF Jenkins to change the same option for many 
Jobs.
Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Wednesday, February 17, 2016 7:21 PM
> To: dev@lucene.apache.org
> Subject: RE: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure
> 
> But why does this fail on Jenkins? Jenkins starts with cleaned checkout
> 
> I will check the Jenkins Config of this Job, maybe it is missing the extra GIT
> checkout option ("git reset").
> 
> Uwe
> 
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> > -Original Message-
> > From: Dawid Weiss [mailto:dawid.we...@gmail.com]
> > Sent: Wednesday, February 17, 2016 4:44 PM
> > To: dev@lucene.apache.org
> > Subject: Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure
> >
> > This is actually very predictable -- if you run it once, it succeeds.
> > If you re-run it then (without cleaning) it always fails, even with
> > -v. I filed this and mention the problem's cause, but I won't have the
> > time to fix it -- sorry!
> >
> > https://issues.apache.org/jira/browse/LUCENE-7033
> >
> > Dawid
> >
> > On Tue, Feb 16, 2016 at 3:50 PM, Michael McCandless
> >  wrote:
> > > OK I ran without -v, piping to a file, and it succeeds.
> > >
> > > Then I run straight to the console, without -v, and it fails.
> > >
> > > I'll see if I can get it to fail with -v...
> > >
> > > Mike McCandless
> > >
> > > http://blog.mikemccandless.com
> > >
> > > On Tue, Feb 16, 2016 at 5:26 AM, Dawid Weiss 
> > wrote:
> > >> Can you:
> > >>
> > >> ant -v > output.log 2>&1
> > >>
> > >> Perhaps it's a timing issue when -v is dumped to the console?
> > >>
> > >> Dawid
> > >>
> > >>
> > >> On Tue, Feb 16, 2016 at 10:59 AM, Michael McCandless
> > >>  wrote:
> > >>> I could still use some help on this one!
> > >>>
> > >>> Somehow this succeeds when I run "ant -v" fails otherwise.
> > >>>
> > >>> Mike McCandless
> > >>>
> > >>> http://blog.mikemccandless.com
> > >>>
> > >>>
> > >>> On Tue, Feb 16, 2016 at 1:32 AM, Apache Jenkins Server
> > >>>  wrote:
> >  Build: https://builds.apache.org/job/Lucene-Artifacts-5.x/1088/
> > 
> >  No tests ran.
> > 
> >  Build Log:
> >  [...truncated 8805 lines...]
> >  BUILD FAILED
> >  /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
> > 5.x/lucene/build.xml:427: The following error occurred while executing this
> > line:
> >  /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
> > 5.x/lucene/build.xml:415: The following error occurred while executing this
> > line:
> >  /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
> > 5.x/lucene/common-build.xml:1724: The following error occurred while
> > executing this line:
> >  /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
> > 5.x/lucene/common-build.xml:608: Error installing artifact
> > 'org.apache.lucene:lucene-core:jar': Error installing artifact: File
> > /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
> > 5.x/lucene/build/lucene.tgz.unpacked/lucene-5.6.0-1088/core/lucene-
> core-
> > 5.6.0-1088.jar does not exist
> > 
> >  Total time: 4 minutes 52 seconds
> >  Build step 'Invoke Ant' marked build as failure
> >  Archiving artifacts
> >  Compressed 167.65 MB of artifacts by 22.5% relative to #1087
> >  Publishing Javadoc
> >  Email was triggered for: Failure - Any
> >  Sending email for trigger: Failure - Any
> > 
> > 
> > 
> > 
> >  -
> >  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >  For additional commands, e-mail: dev-h...@lucene.apache.org
> > >>>
> > >>> -
> > >>> 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
> > >
> >
> > -
> > To unsubscribe, e-mail: 

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+105) - Build # 15913 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15913/
Java: 32bit/jdk-9-ea+105 -server -XX:+UseParallelGC -XX:-UseSuperWord

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.SaslZkACLProviderTest

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=12045, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)2) Thread[id=12043, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)3) Thread[id=12047, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)4) Thread[id=12044, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)5) Thread[id=12046, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=12045, name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at jdk.internal.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
at 

Re: [VOTE] Release Lucene/Solr 5.5.0 RC3

[Dawid Weiss]

SUCCESS! [0:48:21.364275]

I didn't look at the content, but the build succeeded.

Dawid


On Tue, Feb 16, 2016 at 11:36 PM, Michael McCandless
 wrote:
> No problem Uwe, thank you for fixing it!
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Feb 16, 2016 at 5:36 PM, Uwe Schindler  wrote:
>> Thanks Mike,
>>
>> this time all looks fine. Sorry for the hassle with respinning. 
>> Unfortunately the Java 9 release with new unmapping API took longer, so I 
>> was not aware of brokenness of 5.x code.
>>
>> I will run the smoker tomorrow.
>>
>> Thanks Robert for help!
>> Uwe
>>
>> -
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>>
>>> -Original Message-
>>> From: Michael McCandless [mailto:luc...@mikemccandless.com]
>>> Sent: Tuesday, February 16, 2016 10:07 PM
>>> To: Lucene/Solr dev 
>>> Subject: [VOTE] Release Lucene/Solr 5.5.0 RC3
>>>
>>> Please vote for the RC3 release candidate for Lucene/Solr 5.5.0, the
>>> last feature release before Lucene 6.0.0 and the first Lucene/Solr
>>> release since we switched from Subversion to git!
>>>
>>> Artifacts:
>>>
>>>   https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.0-RC3-
>>> rev2a228b3920a07f930f7afb6a42d0d20e184a943c
>>>
>>> Smoke tester:
>>>
>>>   python3 -u dev-tools/scripts/smokeTestRelease.py
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.0-RC3-
>>> rev2a228b3920a07f930f7afb6a42d0d20e184a943c
>>>
>>> Please remember a release is not the time to shove last minute changes
>>> in.  Instead, shove those changes in immediately after the release so
>>> CI has plenty of time to chew on them.
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.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
>

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

RE: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure

[Uwe Schindler]

But why does this fail on Jenkins? Jenkins starts with cleaned checkout

I will check the Jenkins Config of this Job, maybe it is missing the extra GIT 
checkout option ("git reset").

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Dawid Weiss [mailto:dawid.we...@gmail.com]
> Sent: Wednesday, February 17, 2016 4:44 PM
> To: dev@lucene.apache.org
> Subject: Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure
> 
> This is actually very predictable -- if you run it once, it succeeds.
> If you re-run it then (without cleaning) it always fails, even with
> -v. I filed this and mention the problem's cause, but I won't have the
> time to fix it -- sorry!
> 
> https://issues.apache.org/jira/browse/LUCENE-7033
> 
> Dawid
> 
> On Tue, Feb 16, 2016 at 3:50 PM, Michael McCandless
>  wrote:
> > OK I ran without -v, piping to a file, and it succeeds.
> >
> > Then I run straight to the console, without -v, and it fails.
> >
> > I'll see if I can get it to fail with -v...
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> > On Tue, Feb 16, 2016 at 5:26 AM, Dawid Weiss 
> wrote:
> >> Can you:
> >>
> >> ant -v > output.log 2>&1
> >>
> >> Perhaps it's a timing issue when -v is dumped to the console?
> >>
> >> Dawid
> >>
> >>
> >> On Tue, Feb 16, 2016 at 10:59 AM, Michael McCandless
> >>  wrote:
> >>> I could still use some help on this one!
> >>>
> >>> Somehow this succeeds when I run "ant -v" fails otherwise.
> >>>
> >>> Mike McCandless
> >>>
> >>> http://blog.mikemccandless.com
> >>>
> >>>
> >>> On Tue, Feb 16, 2016 at 1:32 AM, Apache Jenkins Server
> >>>  wrote:
>  Build: https://builds.apache.org/job/Lucene-Artifacts-5.x/1088/
> 
>  No tests ran.
> 
>  Build Log:
>  [...truncated 8805 lines...]
>  BUILD FAILED
>  /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
> 5.x/lucene/build.xml:427: The following error occurred while executing this
> line:
>  /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
> 5.x/lucene/build.xml:415: The following error occurred while executing this
> line:
>  /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
> 5.x/lucene/common-build.xml:1724: The following error occurred while
> executing this line:
>  /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
> 5.x/lucene/common-build.xml:608: Error installing artifact
> 'org.apache.lucene:lucene-core:jar': Error installing artifact: File
> /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-
> 5.x/lucene/build/lucene.tgz.unpacked/lucene-5.6.0-1088/core/lucene-core-
> 5.6.0-1088.jar does not exist
> 
>  Total time: 4 minutes 52 seconds
>  Build step 'Invoke Ant' marked build as failure
>  Archiving artifacts
>  Compressed 167.65 MB of artifacts by 22.5% relative to #1087
>  Publishing Javadoc
>  Email was triggered for: Failure - Any
>  Sending email for trigger: Failure - Any
> 
> 
> 
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>  For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
> >>> -
> >>> 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
> >
> 
> -
> 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-trunk-Windows (32bit/jdk1.8.0_72) - Build # 5625 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5625/
Java: 32bit/jdk1.8.0_72 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication

Error Message:
Index: 0, Size: 0

Stack Trace:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at 
__randomizedtesting.SeedInfo.seed([52E3CAF9EB06AE07:A59024A12DEE01E1]:0)
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1241)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11334 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4]   2> Creating dataDir: 

Re: [JENKINS] Lucene-Artifacts-5.x - Build # 1088 - Failure

[Dawid Weiss]

This is actually very predictable -- if you run it once, it succeeds.
If you re-run it then (without cleaning) it always fails, even with
-v. I filed this and mention the problem's cause, but I won't have the
time to fix it -- sorry!

https://issues.apache.org/jira/browse/LUCENE-7033

Dawid

On Tue, Feb 16, 2016 at 3:50 PM, Michael McCandless
 wrote:
> OK I ran without -v, piping to a file, and it succeeds.
>
> Then I run straight to the console, without -v, and it fails.
>
> I'll see if I can get it to fail with -v...
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Tue, Feb 16, 2016 at 5:26 AM, Dawid Weiss  wrote:
>> Can you:
>>
>> ant -v > output.log 2>&1
>>
>> Perhaps it's a timing issue when -v is dumped to the console?
>>
>> Dawid
>>
>>
>> On Tue, Feb 16, 2016 at 10:59 AM, Michael McCandless
>>  wrote:
>>> I could still use some help on this one!
>>>
>>> Somehow this succeeds when I run "ant -v" fails otherwise.
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>>
>>> On Tue, Feb 16, 2016 at 1:32 AM, Apache Jenkins Server
>>>  wrote:
 Build: https://builds.apache.org/job/Lucene-Artifacts-5.x/1088/

 No tests ran.

 Build Log:
 [...truncated 8805 lines...]
 BUILD FAILED
 /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/build.xml:427:
  The following error occurred while executing this line:
 /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/build.xml:415:
  The following error occurred while executing this line:
 /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/common-build.xml:1724:
  The following error occurred while executing this line:
 /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/common-build.xml:608:
  Error installing artifact 'org.apache.lucene:lucene-core:jar': Error 
 installing artifact: File 
 /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/build/lucene.tgz.unpacked/lucene-5.6.0-1088/core/lucene-core-5.6.0-1088.jar
  does not exist

 Total time: 4 minutes 52 seconds
 Build step 'Invoke Ant' marked build as failure
 Archiving artifacts
 Compressed 167.65 MB of artifacts by 22.5% relative to #1087
 Publishing Javadoc
 Email was triggered for: Failure - Any
 Sending email for trigger: Failure - Any




 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>> -
>>> 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
>

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

Re: Solr Ref Guide for 5.5

[Cassandra Targett]

Thanks Uwe!

On Tue, Feb 16, 2016 at 4:38 PM, Uwe Schindler  wrote:

> Hi Cassandra,
>
>
>
> The links were updated!
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Cassandra Targett [mailto:casstarg...@gmail.com]
> *Sent:* Tuesday, February 16, 2016 10:54 PM
> *To:* dev@lucene.apache.org
> *Subject:* Solr Ref Guide for 5.5
>
>
>
> With the Lucene/Solr 5.5 release vote underway, I've started getting the
> Solr Ref Guide ready for release. I'll release manage it again, possibly
> with some help from Hoss since I have a little bit of time off planned the
> next couple of weeks.
>
>
>
> Uwe, will you update the CWIKI javadocs to point to the 5_4_0 paths? As
> described here:
> https://cwiki.apache.org/confluence/display/solr/Internal+-+How+Javadoc+Links+Work
> .
>
>
>
> As always, if you introduced new features or change to 5.5 that should be
> in the Ref Guide, please take a few moments to make updates. I've taken a
> stab at the TODO list from CHANGES.txt here:
> https://cwiki.apache.org/confluence/display/solr/Internal+-+TODO+List.
> Please mark your name next to any you plan to work on so we don't overlap
> efforts.
>
>
>
> I hope to get an RC out by the end of this week; by Monday morning US-time
> at the latest. If anyone needs any help with content or more time, please
> just let me know.
>
>
>
> Cassandra
>

Re: [JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk-9-ea+105) - Build # 15587 - Still Failing!

[Robert Muir]

We got this reproducing 100% and I opened a bug report:

Review ID: JI-9029607


On Wed, Feb 17, 2016 at 12:50 AM, Robert Muir  wrote:
> It may be the same bug triggering all the automaton failures (we have
> had several now with EA 105).
>
> I can trigger it to happen it in a really inefficient way at the
> moment by running the test thousands of times:
> https://issues.apache.org/jira/browse/LUCENE-7032
>
> I tested with it enough to know its unrelated to CompactStrings or any
> of the other options that we randomize in jenkins.
>
> On Tue, Feb 16, 2016 at 4:07 AM, Uwe Schindler  wrote:
>> Hi,
>>
>> yes will do. At the moment I am analyzing the problematic test runs. We had 
>> many other failures last night all looking a bit different (no crushes, but 
>> assertions failing). I will disable compact strings one more time to see if 
>> this makes it better. I still have the feeling that it could be related to 
>> that! But definitely the compact strings issue seen last time looks solved.
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>>
>>> -Original Message-
>>> From: Rory O'Donnell [mailto:rory.odonn...@oracle.com]
>>> Sent: Tuesday, February 16, 2016 9:39 AM
>>> To: dev@lucene.apache.org
>>> Cc: rory.odonn...@oracle.com; 'Dalibor Topic' ;
>>> 'Balchandra Vaidya' ; 'Muneer Kolarkunnu'
>>> 
>>> Subject: Re: [JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk-9-ea+105) - Build
>>> # 15587 - Still Failing!
>>>
>>> Hi Uwe,
>>>
>>> Let us know the incident number if it turns out to be a JDK 9 issue.
>>>
>>> Thanks,Rory
>>>
>>> On 15/02/2016 22:30, Uwe Schindler wrote:
>>> > Hi Rory, hi committers,
>>> >
>>> > Unless this is a new bug in Lucene Master (but there was no related
>>> commit!!!), this looks like a new bug in Java 9 build 105.
>>> >
>>> > Uwe
>>> >
>>> > -
>>> > Uwe Schindler
>>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>>> > http://www.thetaphi.de
>>> > eMail: u...@thetaphi.de
>>> >
>>> >
>>> >> -Original Message-
>>> >> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
>>> >> Sent: Monday, February 15, 2016 11:26 PM
>>> >> To: u...@thetaphi.de; dev@lucene.apache.org
>>> >> Subject: [JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk-9-ea+105) - Build 
>>> >> #
>>> >> 15587 - Still Failing!
>>> >> Importance: Low
>>> >>
>>> >> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15587/
>>> >> Java: 64bit/jdk-9-ea+105 -XX:-UseCompressedOops -XX:+UseG1GC -XX:-
>>> >> UseSuperWord
>>> >>
>>> >> 2 tests failed.
>>> >> FAILED:
>>> >>
>>> org.apache.lucene.search.TestMinShouldMatch2.testNextVaryingNumberOf
>>> >> Terms
>>> >>
>>> >> Error Message:
>>> >>
>>> >>
>>> >> Stack Trace:
>>> >> java.lang.AssertionError
>>> >>at
>>> >>
>>> __randomizedtesting.SeedInfo.seed([F872E59E6028464C:7A3791B3AC63E2D]
>>> >> :0)
>>> >>at
>>> >>
>>> org.apache.lucene.search.BooleanScorer.scoreWindowIntoBitSetAndReplay(
>>> >> BooleanScorer.java:218)
>>> >>at
>>> >>
>>> org.apache.lucene.search.BooleanScorer.scoreWindowMultipleScorers(Bool
>>> >> eanScorer.java:266)
>>> >>at
>>> >>
>>> org.apache.lucene.search.BooleanScorer.scoreWindow(BooleanScorer.java:
>>> >> 311)
>>> >>at
>>> >> org.apache.lucene.search.BooleanScorer.score(BooleanScorer.java:335)
>>> >>at
>>> >>
>>> org.apache.lucene.search.BulkScorerWrapperScorer.refill(BulkScorerWrappe
>>> >> rScorer.java:52)
>>> >>at
>>> >>
>>> org.apache.lucene.search.BulkScorerWrapperScorer.access$500(BulkScorer
>>> >> WrapperScorer.java:25)
>>> >>at
>>> >>
>>> org.apache.lucene.search.BulkScorerWrapperScorer$2.advance(BulkScorer
>>> >> WrapperScorer.java:101)
>>> >>at
>>> >>
>>> org.apache.lucene.search.BulkScorerWrapperScorer$2.nextDoc(BulkScorer
>>> >> WrapperScorer.java:95)
>>> >>at
>>> >>
>>> org.apache.lucene.search.TestMinShouldMatch2.assertNext(TestMinShould
>>> >> Match2.java:157)
>>> >>at
>>> >>
>>> org.apache.lucene.search.TestMinShouldMatch2.testNextVaryingNumberOf
>>> >> Terms(TestMinShouldMatch2.java:278)
>>> >>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> >>at
>>> >>
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
>>> >> ava:62)
>>> >>at
>>> >>
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>>> >> sorImpl.java:43)
>>> >>at java.lang.reflect.Method.invoke(Method.java:520)
>>> >>at
>>> >>
>>> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize
>>> >> dRunner.java:1764)
>>> >>at
>>> >>
>>> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
>>> >> mizedRunner.java:871)
>>> >>at
>>> >>
>>> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando
>>> >> mizedRunner.java:907)
>>> >>at
>>> >>
>>> 

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 3091 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/3091/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.handler.clustering.DistributedClusteringComponentTest.test

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:51185/_vnj/u/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:51185/_vnj/u/collection1
at 
__randomizedtesting.SeedInfo.seed([501CD408E008B061:D848EBD24EF4DD99]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:591)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:895)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:858)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:873)
at 
org.apache.solr.BaseDistributedSearchTestCase.del(BaseDistributedSearchTestCase.java:544)
at 
org.apache.solr.handler.clustering.DistributedClusteringComponentTest.test(DistributedClusteringComponentTest.java:35)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:990)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (LUCENE-7032) jdk-9-ea+105 breaks MinimizeOperations.minimize()

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7032:
---

Fails on Windows, too (Java HotSpot(TM) 64-Bit Server VM (build 
9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode):

{noformat}
   [junit4] Suite: org.apache.lucene.util.automaton.TestMinimize
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestMinimize 
-Dtests.method=testBasic -Dtests.seed=5E1BF6106DCA9EC9 -Dtests.locale=fr-GF 
-Dtests.timezone=Africa/Khartoum -Dtests.asserts=true 
-Dtests.file.encoding=Cp1252
   [junit4] ERROR   0.69s | TestMinimize.testBasic <<<
   [junit4]> Throwable #1: java.lang.IllegalArgumentException: source=3 is 
out of bounds (maxState is 2)
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([5E1BF6106DCA9EC9:F5E1EB05B21618E7]:0)
   [junit4]>at 
org.apache.lucene.util.automaton.Automaton.addTransition(Automaton.java:165)
   [junit4]>at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:245)
   [junit4]>at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:537)
   [junit4]>at 
org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
   [junit4]>at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:519)
   [junit4]>at 
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
   [junit4]>at 
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
   [junit4]>at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomSingleAutomaton(AutomatonTestUtil.java:262)
   [junit4]>at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomAutomaton(AutomatonTestUtil.java:276)
   [junit4]>at 
org.apache.lucene.util.automaton.TestMinimize.testBasic(TestMinimize.java:30)
   [junit4]>at java.lang.Thread.run(Thread.java:804)
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene60): {}, 
docValues:{}, sim=RandomSimilarity(queryNorm=true,coord=no): {}, locale=fr-GF, 
timezone=Africa/Khartoum
   [junit4]   2> NOTE: Windows 7 6.1 amd64/Oracle Corporation 9-ea 
(64-bit)/cpus=8,threads=1,free=94388736,total=130023424
   [junit4]   2> NOTE: All tests run in this JVM: [TestMinimize]
   [junit4] Completed [1/1 (1!)] in 1.60s, 1 test, 1 error <<< FAILURES!
   [junit4]
   [junit4]
   [junit4] Tests with failures [seed: 5E1BF6106DCA9EC9]:
   [junit4]   - org.apache.lucene.util.automaton.TestMinimize.testBasic
   [junit4]
   [junit4]
   [junit4] JVM J0: 0.88 .. 3.61 = 2.73s
   [junit4] Execution time total: 3.64 sec.
   [junit4] Tests summary: 1 suite, 1 test, 1 error
{noformat}

> jdk-9-ea+105 breaks MinimizeOperations.minimize()
> -
>
> Key: LUCENE-7032
> URL: https://issues.apache.org/jira/browse/LUCENE-7032
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Robert Muir
>  Labels: Java9
>
> As soon as jdk-9-ea+105 was put into test rotation, automaton tests have been 
> sporatically failing in non-reproducible ways. All of them invoke hopcroft 
> minimization either directly or indirectly.
> The bug manifests in several forms:
> * ArrayIndexOutOfBoundsException in minimize()
> * IllegalArgumentException for an explicit bounds check
> * incorrect resulting automaton
> This method is ... let's say not the ideal one to debug something like this, 
> but I've at least got it where I can make it fail in a few minutes with 
> beasting, so we can try simple things like turning on/off jvm flags to try to 
> narrow it more.
> It would be really great to make it fail more efficiently, but unfortunately 
> it takes many thousands of iterations until we understand more about it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-7032) jdk-9-ea+105 breaks MinimizeOperations.minimize()

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-7032:
--
Affects Version/s: master

> jdk-9-ea+105 breaks MinimizeOperations.minimize()
> -
>
> Key: LUCENE-7032
> URL: https://issues.apache.org/jira/browse/LUCENE-7032
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Robert Muir
>  Labels: Java9
>
> As soon as jdk-9-ea+105 was put into test rotation, automaton tests have been 
> sporatically failing in non-reproducible ways. All of them invoke hopcroft 
> minimization either directly or indirectly.
> The bug manifests in several forms:
> * ArrayIndexOutOfBoundsException in minimize()
> * IllegalArgumentException for an explicit bounds check
> * incorrect resulting automaton
> This method is ... let's say not the ideal one to debug something like this, 
> but I've at least got it where I can make it fail in a few minutes with 
> beasting, so we can try simple things like turning on/off jvm flags to try to 
> narrow it more.
> It would be really great to make it fail more efficiently, but unfortunately 
> it takes many thousands of iterations until we understand more about it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-7032) jdk-9-ea+105 breaks MinimizeOperations.minimize()

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-7032:
--
Labels: Java9  (was: )

> jdk-9-ea+105 breaks MinimizeOperations.minimize()
> -
>
> Key: LUCENE-7032
> URL: https://issues.apache.org/jira/browse/LUCENE-7032
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Robert Muir
>  Labels: Java9
>
> As soon as jdk-9-ea+105 was put into test rotation, automaton tests have been 
> sporatically failing in non-reproducible ways. All of them invoke hopcroft 
> minimization either directly or indirectly.
> The bug manifests in several forms:
> * ArrayIndexOutOfBoundsException in minimize()
> * IllegalArgumentException for an explicit bounds check
> * incorrect resulting automaton
> This method is ... let's say not the ideal one to debug something like this, 
> but I've at least got it where I can make it fail in a few minutes with 
> beasting, so we can try simple things like turning on/off jvm flags to try to 
> narrow it more.
> It would be really great to make it fail more efficiently, but unfortunately 
> it takes many thousands of iterations until we understand more about it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7032) jdk-9-ea+105 breaks MinimizeOperations.minimize()

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7032:
---

Hi,
I think we are now fine to open bug report. I did this several times. Maybe use 
older bug as template:
- How to checkout lucene-core (modify to use GIT)
- How to run the test (above command line)
- How to get pure "java" command line with "ant -verbose"

The OpenJDK developers (e.g., Roland Westrelin) were able to reproduce and 
debug. I think thats enough. I would not spend too much time in debugging this.

> jdk-9-ea+105 breaks MinimizeOperations.minimize()
> -
>
> Key: LUCENE-7032
> URL: https://issues.apache.org/jira/browse/LUCENE-7032
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Robert Muir
>  Labels: Java9
>
> As soon as jdk-9-ea+105 was put into test rotation, automaton tests have been 
> sporatically failing in non-reproducible ways. All of them invoke hopcroft 
> minimization either directly or indirectly.
> The bug manifests in several forms:
> * ArrayIndexOutOfBoundsException in minimize()
> * IllegalArgumentException for an explicit bounds check
> * incorrect resulting automaton
> This method is ... let's say not the ideal one to debug something like this, 
> but I've at least got it where I can make it fail in a few minutes with 
> beasting, so we can try simple things like turning on/off jvm flags to try to 
> narrow it more.
> It would be really great to make it fail more efficiently, but unfortunately 
> it takes many thousands of iterations until we understand more about it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3

[Joakim Erdfelt (JIRA)]

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

Joakim Erdfelt commented on SOLR-7339:
--

>From the gut:

Option 1)
You have multiple jetty-http.jars, and one of them is really old.
Unfortunately, your system picked the old one over the new one.

Option 2)
You had a fundamental jvm runtime issue preventing that class from being 
initialized (memory, file descriptors, bad jars, etc..)
Do you have any other log entries that could indicate this sort of issue?

Option 3)
You have a version mismatch between jetty-server.jar and jetty-http.jar

Option 4)
You have jetty-http.jar in your WEB-INF/lib and a testcase that flips the 
WebAppContext loaderPriority improperly




> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-7339-revert.patch, SOLR-7339.patch, 
> SOLR-7339.patch, SOLR-7339.patch, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7032) jdk-9-ea+105 breaks MinimizeOperations.minimize()

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7032:
-

Thanks dawid, I optimized test parameters further and experimented with your 
suggestions.

It now fails 100% reproducible for me with a single test method invocation on 
my linux machine (4 seconds):

{noformat}
rmuir@beast:~/workspace/lucene-solr/lucene/core$ ant test 
-Dtestcase=TestMinimize -Dtests.method="testBasic*" 
-Dtests.seed=5E1BF6106DCA9EC9 -Dargs="-XX:-TieredCompilation -Xbatch"

<<< anting >>>

-test:
[junit4:pickseed] Seed property 'tests.seed' already defined: 5E1BF6106DCA9EC9
   [junit4]  says g'day! Master seed: 5E1BF6106DCA9EC9
   [junit4] Executing 1 suite with 1 JVM.
   [junit4] 
   [junit4] Started J0 PID(5919@localhost).
   [junit4] Suite: org.apache.lucene.util.automaton.TestMinimize
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestMinimize 
-Dtests.method=testBasic -Dtests.seed=5E1BF6106DCA9EC9 -Dtests.locale=fr-GF 
-Dtests.timezone=Africa/Khartoum -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.59s | TestMinimize.testBasic <<<
   [junit4]> Throwable #1: java.lang.IllegalArgumentException: source=3 is 
out of bounds (maxState is 2)
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([5E1BF6106DCA9EC9:F5E1EB05B21618E7]:0)
   [junit4]>at 
org.apache.lucene.util.automaton.Automaton.addTransition(Automaton.java:165)
   [junit4]>at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:245)
   [junit4]>at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:537)
   [junit4]>at 
org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
   [junit4]>at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:519)
   [junit4]>at 
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
   [junit4]>at 
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
   [junit4]>at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomSingleAutomaton(AutomatonTestUtil.java:262)
   [junit4]>at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomAutomaton(AutomatonTestUtil.java:276)
   [junit4]>at 
org.apache.lucene.util.automaton.TestMinimize.testBasic(TestMinimize.java:30)
   [junit4]>at java.lang.Thread.run(Thread.java:804)
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene60): {}, 
docValues:{}, sim=RandomSimilarity(queryNorm=true,coord=no): {}, locale=fr-GF, 
timezone=Africa/Khartoum
   [junit4]   2> NOTE: Linux 4.2.0-25-generic amd64/Oracle Corporation 9-ea 
(64-bit)/cpus=8,threads=1,free=162224128,total=197132288
   [junit4]   2> NOTE: All tests run in this JVM: [TestMinimize]
   [junit4] Completed [1/1 (1!)] in 1.69s, 1 test, 1 error <<< FAILURES!
   [junit4] 
   [junit4] 
   [junit4] Tests with failures [seed: 5E1BF6106DCA9EC9]:
   [junit4]   - org.apache.lucene.util.automaton.TestMinimize.testBasic
   [junit4] 
   [junit4] 
   [junit4] JVM J0: 0.58 .. 2.96 = 2.38s
   [junit4] Execution time total: 2.98 sec.
   [junit4] Tests summary: 1 suite, 1 test, 1 error

BUILD FAILED
/home/rmuir/workspace/lucene-solr/lucene/common-build.xml:1457: The following 
error occurred while executing this line:
/home/rmuir/workspace/lucene-solr/lucene/common-build.xml:1014: There were test 
failures: 1 suite, 1 test, 1 error [seed: 5E1BF6106DCA9EC9]

Total time: 4 seconds
{noformat}

Now, to think about how to boil it down from here.

> jdk-9-ea+105 breaks MinimizeOperations.minimize()
> -
>
> Key: LUCENE-7032
> URL: https://issues.apache.org/jira/browse/LUCENE-7032
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> As soon as jdk-9-ea+105 was put into test rotation, automaton tests have been 
> sporatically failing in non-reproducible ways. All of them invoke hopcroft 
> minimization either directly or indirectly.
> The bug manifests in several forms:
> * ArrayIndexOutOfBoundsException in minimize()
> * IllegalArgumentException for an explicit bounds check
> * incorrect resulting automaton
> This method is ... let's say not the ideal one to debug something like this, 
> but I've at least got it where I can make it fail in a few minutes with 
> beasting, so we can try simple things like turning on/off jvm flags to try to 
> narrow it more.
> It would be really great to make it fail more efficiently, but unfortunately 
> it takes many thousands of iterations until we understand more about it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To 

[jira] [Commented] (SOLR-8349) Allow sharing of large in memory data structures across cores

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-8349:


Actually in my particular case since all cores need it anyway I'm just loading 
using parallel streaming and enough threads to soak up all CPU on the box until 
processing finishes... That's probably not a good solution for the general use 
case though. 

Anywho, after punting Goal 3 guava works easy as pie, updating to merge with 
latest if any now.

> Allow sharing of large in memory data structures across cores
> -
>
> Key: SOLR-8349
> URL: https://issues.apache.org/jira/browse/SOLR-8349
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.3
>Reporter: Gus Heck
> Attachments: SOLR-8349.patch
>
>
> In some cases search components or analysis classes may utilize a large 
> dictionary or other in-memory structure. When multiple cores are loaded with 
> identical configurations utilizing this large in memory structure, each core 
> holds it's own copy in memory. This has been noted in the past and a specific 
> case reported in SOLR-3443. This patch provides a generalized capability, and 
> if accepted, this capability will then be used to fix SOLR-3443.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-839) XML Query Parser support (deftype=xmlparser)

[Christine Poerschke (JIRA)]

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

Christine Poerschke edited comment on SOLR-839 at 2/17/16 3:48 PM:
---

Created LUCENE-7034 wishing for org.apache.lucene.queryparser.xml 
javadocs/examples - noticed when drafting the Solr Reference Guide's [XML Query 
Parser|https://cwiki.apache.org/confluence/display/solr/Other+Parsers#OtherParsers-XMLQueryParser]
 sub-section.


was (Author: cpoerschke):
Noticed when drafting the Solr Reference Guide's [XML Query 
Parser|https://cwiki.apache.org/confluence/display/solr/Other+Parsers#OtherParsers-XMLQueryParser]
 sub-section.

> XML Query Parser support (deftype=xmlparser)
> 
>
> Key: SOLR-839
> URL: https://issues.apache.org/jira/browse/SOLR-839
> Project: Solr
>  Issue Type: New Feature
>  Components: query parsers
>Affects Versions: 1.3, 5.4, master
>Reporter: Erik Hatcher
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, master
>
> Attachments: SOLR-839-object-parser.patch, SOLR-839.patch, 
> SOLR-839.patch, SOLR-839.patch, lucene-xml-query-parser-2.4-dev.jar
>
>
> Lucene includes a query parser that is able to create the full-spectrum of 
> Lucene queries, using an XML data structure.
> This patch adds "xml" query parser support to Solr.
> Example (from 
> {{lucene/queryparser/src/test/org/apache/lucene/queryparser/xml/NestedBooleanQuery.xml}}):
> {code}
>   
>   
> 
>   
> 
> doesNotExistButShouldBeOKBecauseOtherClauseExists
>   
> 
>   
>   
> bank
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-8686) Install Script hard codes the SOLR_ENV path in /etc/init.d/solr

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-8686:
---

 Summary: Install Script hard codes the SOLR_ENV path in 
/etc/init.d/solr
 Key: SOLR-8686
 URL: https://issues.apache.org/jira/browse/SOLR-8686
 Project: Solr
  Issue Type: Bug
  Components: scripts and tools
Affects Versions: 5.4.1
Reporter: Susheel Kumar


Until Solr-5.3.1 (that i am aware of), the install script would set the right 
SOLR_ENV path in /etc/init.d/solr which is passed as -d "Directory for live / 
writable Solr files..."  but with solr-5.4.1 i see it always sets to 
/etc/default/solr.in.sh.  
Below is diff snippet of install_solr_service.sh of 5.3.1 vs 5.4.1


 
sed_expr1="s#SOLR_INSTALL_DIR=.*#SOLR_INSTALL_DIR=$SOLR_EXTRACT_DIR/$SOLR_SERVICE#"
< sed_expr2="s#SOLR_ENV=.*#SOLR_ENV=$SOLR_VAR_DIR/solr.in.sh#"
< sed_expr3="s#RUNAS=.*#RUNAS=$SOLR_USER#"
---
> sed_expr1="s#SOLR_INSTALL_DIR=.*#SOLR_INSTALL_DIR=\"$SOLR_EXTRACT_DIR/$SOLR_SERVICE\"#"
> sed_expr2="s#SOLR_ENV=.*#SOLR_ENV=\"/etc/default/$SOLR_SERVICE.in.sh\"#"
> sed_expr3="s#RUNAS=.*#RUNAS=\"$SOLR_USER\"#"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-839) XML Query Parser support (deftype=xmlparser)

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-839:
--

Noticed when drafting the Solr Reference Guide's [XML Query 
Parser|https://cwiki.apache.org/confluence/display/solr/Other+Parsers#OtherParsers-XMLQueryParser]
 sub-section.

> XML Query Parser support (deftype=xmlparser)
> 
>
> Key: SOLR-839
> URL: https://issues.apache.org/jira/browse/SOLR-839
> Project: Solr
>  Issue Type: New Feature
>  Components: query parsers
>Affects Versions: 1.3, 5.4, master
>Reporter: Erik Hatcher
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, master
>
> Attachments: SOLR-839-object-parser.patch, SOLR-839.patch, 
> SOLR-839.patch, SOLR-839.patch, lucene-xml-query-parser-2.4-dev.jar
>
>
> Lucene includes a query parser that is able to create the full-spectrum of 
> Lucene queries, using an XML data structure.
> This patch adds "xml" query parser support to Solr.
> Example (from 
> {{lucene/queryparser/src/test/org/apache/lucene/queryparser/xml/NestedBooleanQuery.xml}}):
> {code}
>   
>   
> 
>   
> 
> doesNotExistButShouldBeOKBecauseOtherClauseExists
>   
> 
>   
>   
> bank
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-7033) ant prepare-release-no-sign fails intermittently

[Dawid Weiss (JIRA)]

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

Dawid Weiss updated LUCENE-7033:

Attachment: capture-2.png

> ant prepare-release-no-sign fails intermittently
> 
>
> Key: LUCENE-7033
> URL: https://issues.apache.org/jira/browse/LUCENE-7033
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Priority: Minor
> Attachments: capture-2.png
>
>
> Mike reported this on the mailing list. This is fully reproducible, you just 
> need to run it twice:
> {code}
> cd lucene
> # succeeds
> ant prepare-release-no-sign
> # fails
> ant prepare-release-no-sign
> {code}
> The problem is with this target that runs conditionally:
> {code}
>   
> 
>   
> 
> 
>  dest="${lucene.tgz.unpack.dir}">
>   
> 
>   
> {code}
> I attach a diff from the two runs -- you can see the second one skipped this 
> task and then cleaned the output folder, which doesn't make sense.
> I don't know how to fix, but I think it's this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-7034) org.apache.lucene.queryparser.xml javadocs/examples

[Christine Poerschke (JIRA)]

Christine Poerschke created LUCENE-7034:
---

 Summary: org.apache.lucene.queryparser.xml javadocs/examples
 Key: LUCENE-7034
 URL: https://issues.apache.org/jira/browse/LUCENE-7034
 Project: Lucene - Core
  Issue Type: Wish
Reporter: Christine Poerschke
Priority: Minor


It would be nice if javadocs for 
[CoreParser|http://lucene.apache.org/core/5_4_1/queryparser/org/apache/lucene/queryparser/xml/CoreParser.html]
 mentioned/linked all the used 
[QueryBuilder|http://lucene.apache.org/core/5_4_1/queryparser/org/apache/lucene/queryparser/xml/QueryBuilder.html]
 classes and if each of those classes e.g. 
[BooleanQueryBuilder|http://lucene.apache.org/core/5_4_1/queryparser/org/apache/lucene/queryparser/xml/builders/BooleanQueryBuilder.html]
 in its javadocs had an example illustrating sub-elements and attributes used 
by that particular builder.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-7033) ant prepare-release-no-sign fails intermittently

[Dawid Weiss (JIRA)]

Dawid Weiss created LUCENE-7033:
---

 Summary: ant prepare-release-no-sign fails intermittently
 Key: LUCENE-7033
 URL: https://issues.apache.org/jira/browse/LUCENE-7033
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor


Mike reported this on the mailing list. This is fully reproducible, you just 
need to run it twice:
{code}
cd lucene
# succeeds
ant prepare-release-no-sign
# fails
ant prepare-release-no-sign
{code}

The problem is with this target that runs conditionally:
{code}
  

  



  

  
{code}

I attach a diff from the two runs -- you can see the second one skipped this 
task and then cleaned the output folder, which doesn't make sense.

I don't know how to fix, but I think it's this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 1100 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/1100/

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler

Error Message:
ObjectTracker found 7 object(s) that were not released!!! [NRTCachingDirectory, 
NRTCachingDirectory, NRTCachingDirectory, NRTCachingDirectory, 
NRTCachingDirectory, NRTCachingDirectory, NRTCachingDirectory]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 7 object(s) that were not 
released!!! [NRTCachingDirectory, NRTCachingDirectory, NRTCachingDirectory, 
NRTCachingDirectory, NRTCachingDirectory, NRTCachingDirectory, 
NRTCachingDirectory]
at __randomizedtesting.SeedInfo.seed([3D49B6BCFBA4BC04]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:228)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

Error Message:
Test abandoned because suite timeout was reached.

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


FAILED:  
junit.framework.TestSuite.org.apache.solr.security.BasicAuthIntegrationTest

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

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


FAILED:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:56311/cu_i/fg

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:56311/cu_i/fg
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:585)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:375)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:502)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:162)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 

[jira] [Commented] (SOLR-8453) Jetty update from 9.2 to 9.3 causes the server to reset formerly legitimate client connections.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8453:
---

Yeah, we are doing it in a filter, but we were just doing it on failures. I 
suspect some other code changes have exposed that we really should be doing it 
every request, but I've made that change. Currently, we don't really want the 
client or server to give up early in any case if we can help it. Since this 
issue is released, I filed a new JIRA for it, SOLR-8683 Always consume the full 
request on the server, not just in the case of an error.

> Jetty update from 9.2 to 9.3 causes the server to reset formerly legitimate 
> client connections.
> ---
>
> Key: SOLR-8453
> URL: https://issues.apache.org/jira/browse/SOLR-8453
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 5.5, master
>
> Attachments: SOLR-8453.patch, SOLR-8453.patch, SOLR-8453.patch, 
> SOLR-8453.patch, SOLR-8453.patch, SOLR-8453.patch, SOLR-8453.patch, 
> SOLR-8453.patch, SOLR-8453.patch, SOLR-8453_test.patch, SOLR-8453_test.patch, 
> jetty9.2.pcapng, jetty9.3.pcapng
>
>
> The basic problem is that when we are streaming in updates via a client, an 
> update can fail in a way that further updates in the request will not be 
> processed, but not in a way that causes the client to stop and finish up the 
> request before the server does something else with that connection.
> This seems to mean that even after the server stops processing the request, 
> the concurrent update client is still in the process of sending the request. 
> It seems previously, Jetty would not go after the connection very quickly 
> after the server processing thread was stopped via exception, and the client 
> (usually?) had time to clean up properly. But after the Jetty upgrade from 
> 9.2 to 9.3, Jetty closes the connection on the server sooner than previous 
> versions (?), and the client does not end up getting notified of the original 
> exception at all and instead hits a connection reset exception. The result 
> was random fails due to connection reset throughout our tests and one 
> particular test failing consistently. Even before this update, it does not 
> seem like we are acting in a safe or 'behaved' manner, but our version of 
> Jetty was relaxed enough (or a bug was fixed?) for our tests to work out.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7339:
---

Well, at least they are repeatable fails.

Not sure what it is yet, but fails seem to have the following that I don't see 
in passes:

{noformat}
23813 DEBUG (qtp1185380035-63) [] o.e.j.i.ManagedSelector 
java.lang.NoClassDefFoundError: Could not initialize class 
org.eclipse.jetty.http.HttpParser
at 
org.eclipse.jetty.server.HttpConnection.newHttpParser(HttpConnection.java:124)
at 
org.eclipse.jetty.server.HttpConnection.(HttpConnection.java:102)
at 
org.eclipse.jetty.server.HttpConnectionFactory.newConnection(HttpConnectionFactory.java:58)
at 
org.eclipse.jetty.server.ServerConnector$ServerConnectorManager.newConnection(ServerConnector.java:510)
at 
org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:411)
at 
org.eclipse.jetty.io.ManagedSelector.access$1600(ManagedSelector.java:56)
at 
org.eclipse.jetty.io.ManagedSelector$CreateEndPoint.run(ManagedSelector.java:587)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:213)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.execute(ExecuteProduceConsume.java:101)
at org.eclipse.jetty.io.ManagedSelector.run(ManagedSelector.java:136)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
at java.lang.Thread.run(Thread.java:745)
{noformat}

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-7339-revert.patch, SOLR-7339.patch, 
> SOLR-7339.patch, SOLR-7339.patch, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3

[Greg Wilkins (JIRA)]

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

Greg Wilkins commented on SOLR-7339:


Yell if there is anything you want us to look at!

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-7339-revert.patch, SOLR-7339.patch, 
> SOLR-7339.patch, SOLR-7339.patch, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7339:
---

Darn, sometimes I'm still seeing connection reset problems. But much rarer.

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-7339-revert.patch, SOLR-7339.patch, 
> SOLR-7339.patch, SOLR-7339.patch, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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