date:20160227

[jira] [Commented] (LUCENE-7052) BytesRefHash.sort should always sort in unicode code point order

2016-02-27 Thread Dawid Weiss (JIRA)


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

Dawid Weiss commented on LUCENE-7052:
-

Neither is actually pretty as the treeset invokes a comparator multiple times 
for the same string, causing multiple identical string-int[] conversions along 
the way. This is test-method only though, so it doesn't matter much.

> BytesRefHash.sort should always sort in unicode code point order
> 
>
> Key: LUCENE-7052
> URL: https://issues.apache.org/jira/browse/LUCENE-7052
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master, 6.0
>
> Attachments: LUCENE-7052.patch
>
>
> Today {{BytesRefHash.sort}} takes a custom {{Comparator}} but we always pass 
> it {{BytesRef.getUTF8SortedAsUnicodeComparator()}}.



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

2016-02-27 Thread Apache Jenkins Server

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

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:55705//collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:55705//collection1
at 
__randomizedtesting.SeedInfo.seed([9B05B849FE754E5F:13518793508923A7]: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:551)
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: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 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1022)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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

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

2016-02-27 Thread Policeman Jenkins Server

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

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

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [NRTCachingDirectory]
at __randomizedtesting.SeedInfo.seed([ED65A817F3D37368]: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:238)
at sun.reflect.GeneratedMethodAccessor31.invoke(Unknown Source)
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$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)




Build Log:
[...truncated 10811 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_ED65A817F3D37368-001/init-core-data-001
   [junit4]   2> 1173722 INFO  
(TEST-TestReplicationHandler.doTestDetails-seed#[ED65A817F3D37368]) [] 
o.a.s.SolrTestCaseJ4 ###Starting doTestDetails
   [junit4]   2> 1173723 INFO  
(TEST-TestReplicationHandler.doTestDetails-seed#[ED65A817F3D37368]) [] 
o.a.s.SolrTestCaseJ4 Writing core.properties file to 
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_ED65A817F3D37368-001/solr-instance-001/collection1
   [junit4]   2> 1173727 INFO  
(TEST-TestReplicationHandler.doTestDetails-seed#[ED65A817F3D37368]) [] 
o.e.j.s.Server jetty-9.3.6.v20151106
   [junit4]   2> 1173728 INFO  
(TEST-TestReplicationHandler.doTestDetails-seed#[ED65A817F3D37368]) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@6b0acbe{/solr,null,AVAILABLE}
   [junit4]   2> 1173730 INFO  
(TEST-TestReplicationHandler.doTestDetails-seed#[ED65A817F3D37368]) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@23191e40{HTTP/1.1,[http/1.1]}{127.0.0.1:37861}
   [junit4]   2> 1173730 INFO  
(TEST-TestReplicationHandler.doTestDetails-seed#[ED65A817F3D37368]) [] 
o.e.j.s.Server Started @1177007ms
   [junit4]   2> 1173730 INFO  
(TEST-TestReplicationHandler.doTestDetails-seed#[ED65A817F3D37368]) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: 
{solr.data.dir=/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_ED65A817F3D37368-001/solr-instance-001/collection1/data,
 hostContext=/solr, hostPort=37861}
   [junit4]   2> 1173730 INFO

[JENKINS] Lucene-Solr-5.5-MacOSX (64bit/jdk1.7.0) - Build # 18 - Still Failing!

2016-02-27 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-MacOSX/18/
Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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([C073A7AD3DA9EFAC:EC0AE32848102709]: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: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)




Build Log:
[...truncated 10547 lines...]
   [junit4] Suite: org.apache.solr.update.DirectUpdateHandlerTest

[jira] [Commented] (SOLR-7516) Improve javadocs for JavaBinCodec, ObjectResolver and enforce the single-usage policy

2016-02-27 Thread Benoit Vanalderweireldt (JIRA)


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

Benoit Vanalderweireldt commented on SOLR-7516:
---

I'm looking at your patch and will add test cases and comments then will push 
it for you.

> Improve javadocs for JavaBinCodec, ObjectResolver and enforce the 
> single-usage policy
> -
>
> Key: SOLR-7516
> URL: https://issues.apache.org/jira/browse/SOLR-7516
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
>  Labels: difficulty-easy, newdev
> Fix For: 5.2, master
>
> Attachments: SOLR-7516.patch
>
>
> The Javadocs of this class can use some improvements. It doesn't adequately 
> describe the purpose of the ObjectResolver. Also, since it says that this 
> object should be used only once for marshalling or unmarshalling operation, 
> we should enforce it in code via asserts and/or exceptions.



--
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 # 889 - Still Failing

2016-02-27 Thread Apache Jenkins Server

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

64 tests failed.
FAILED:  org.apache.solr.cloud.CdcrVersionReplicationTest.testCdcrDocVersions

Error Message:
The collection (tmp_collection) is still present - waited for 15 seconds

Stack Trace:
java.lang.AssertionError: The collection (tmp_collection) is still present - 
waited for 15 seconds
at 
__randomizedtesting.SeedInfo.seed([A99EC9566ABE25ED:5108C2F498D8CAF1]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForCollectionToDisappear(AbstractDistribZkTestBase.java:206)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForCollectionToDisappear(BaseCdcrDistributedZkTest.java:489)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.startServers(BaseCdcrDistributedZkTest.java:589)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.createSourceCollection(BaseCdcrDistributedZkTest.java:339)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.baseBefore(BaseCdcrDistributedZkTest.java:161)
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$9.evaluate(RandomizedRunner.java:905)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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

[jira] [Created] (SOLR-8754) Adding test cases for org.apache.solr.util.hll.NumberUtilTest

2016-02-27 Thread Benoit Vanalderweireldt (JIRA)

Benoit Vanalderweireldt created SOLR-8754:
-

 Summary: Adding test cases for 
org.apache.solr.util.hll.NumberUtilTest 
 Key: SOLR-8754
 URL: https://issues.apache.org/jira/browse/SOLR-8754
 Project: Solr
  Issue Type: Improvement
  Components: Tests
Reporter: Benoit Vanalderweireldt
Priority: Trivial


Added test cases for org.apache.solr.util.hll.NumberUtilTest :

 - NumberUtil.log2
 - NumberUtil.toHex
 - NumberUtil.fromHex



--
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-8743) Data loss on shard recovery and leader election

2016-02-27 Thread Matt Weber (JIRA)


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

Matt Weber commented on SOLR-8743:
--

Thank you for reopening, I feel it is a bug in step 6.  In step 5 when NodeA 
comes back online, it stays down (I assume) because it knows NodeB should be 
the primary due to the state in ZK that never went down.  In step 6 when NodeB 
comes back online, it *should* pick NodeB as the primary and sync from there, 
however it appears to pick the first node that came online even if it has stale 
data.  If step 6 never happens, I think it should stay down forever or until 
the user forces it back online.

> Data loss on shard recovery and leader election
> ---
>
> Key: SOLR-8743
> URL: https://issues.apache.org/jira/browse/SOLR-8743
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5
>Reporter: Matt Weber
>
> SolrCloud with 3 external ZK nodes in quorum, 2 data nodes (NodeA and NodeB). 
>  Single collection that has a single shard and a single replica (replication 
> factor 2).  The primary shard is initially on NodeA and the replica on NodeB.
> 1.  Index Doc1 via NodeA
> ./solr/bin/post -c people -d ' name="id">1'
> 2.  Shutdown NodeA, NodeB becomes the primary. Doc1 is searchable.
> 3.  Delete Doc1 and index Doc2 via NodeB.
> ./solr/bin/post -c people -d "1"
> ./solr/bin/post -c people -d ' name="id">2'
> 4.  Shutdown NodeB, no nodes online.  ZK still up.
> 5.  Start NodeA, it remains in "down" status since NodeB is down and it was 
> last seen as the primary.
> 6.  Start NodeB, it comes online in  "down" status.  NodeA is elected leader 
> and sync starts.  Doc2 is gone, Doc1 exists in both shards.



--
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-7052) BytesRefHash.sort should always sort in unicode code point order

2016-02-27 Thread Steve Rowe (JIRA)


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

Steve Rowe commented on LUCENE-7052:


Mike, why did you add an implementation of codePoints() instead of using the 
CharSequence version (returning IntStream) + toArray()?  The test passes for me 
with this patch:

{noformat}
diff --git a/lucene/core/src/test/org/apache/lucene/util/TestBytesRefHash.java 
b/lucene/core/src/test/org/apache/lucene/util/TestBytesRefHash.java
index 50d921b..c3a58ff 100644
--- a/lucene/core/src/test/org/apache/lucene/util/TestBytesRefHash.java
+++ b/lucene/core/src/test/org/apache/lucene/util/TestBytesRefHash.java
@@ -168,15 +168,6 @@ public class TestBytesRefHash extends LuceneTestCase {
 }
   }
 
-  private static int[] codePoints(String input) {
-int length = Character.codePointCount(input, 0, input.length());
-int word[] = new int[length];
-for (int i = 0, j = 0, cp = 0; i < input.length(); i += 
Character.charCount(cp)) {
-  word[j++] = cp = input.codePointAt(i);
-}
-return word;
-  }
-
   /**
* Test method for
* {@link org.apache.lucene.util.BytesRefHash#sort()}.
@@ -191,8 +182,8 @@ public class TestBytesRefHash extends LuceneTestCase {
   SortedSet strings = new TreeSet<>(new Comparator() {
   @Override
   public int compare(String a, String b) {
-int[] aCodePoints = codePoints(a);
-int[] bCodePoints = codePoints(b);
+int[] aCodePoints = a.codePoints().toArray();
+int[] bCodePoints = b.codePoints().toArray();
 for(int i=0;i BytesRefHash.sort should always sort in unicode code point order
> 
>
> Key: LUCENE-7052
> URL: https://issues.apache.org/jira/browse/LUCENE-7052
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master, 6.0
>
> Attachments: LUCENE-7052.patch
>
>
> Today {{BytesRefHash.sort}} takes a custom {{Comparator}} but we always pass 
> it {{BytesRef.getUTF8SortedAsUnicodeComparator()}}.



--
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-8713) New UI points to the wiki for Query Syntax instead of the Reference Guide

2016-02-27 Thread JIRA


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

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

I do believe that having a documentation snapshot per release (other than the 
pdf) would be better for linking in the code/UI, but not having that, I think 
the ref guide is the best place right now. Most parts of the wiki are outdated 
or not being maintained, plus the old UI is linking to the ref guide, I don't 
believe the new UI switched back to the wiki intentionally.
If nobody is against this change in particular I'll commit it, PR looks good to 
me. 

> New UI points to the wiki for Query Syntax instead of the Reference Guide
> -
>
> Key: SOLR-8713
> URL: https://issues.apache.org/jira/browse/SOLR-8713
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: master
>Reporter: Tomás Fernández Löbbe
>Priority: Trivial
>  Labels: newdev
>
> Old Admin UI points to 
> https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing but 
> the new one points to http://wiki.apache.org/solr/SolrQuerySyntax



--
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-5.5-Windows (32bit/jdk1.8.0_72) - Build # 35 - Failure!

2016-02-27 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Windows/35/
Java: 32bit/jdk1.8.0_72 -server -XX:+UseConcMarkSweepGC

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

Error Message:
Should've returned a 401 error

Stack Trace:
java.lang.AssertionError: Should've returned a 401 error
at 
__randomizedtesting.SeedInfo.seed([E47929A367D31986:D9A1878F5F3D47F6]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.TestAuthenticationFramework.testBasics(TestAuthenticationFramework.java:103)
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)


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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestAuthenticationFramework: 1) Thread[id=5052, 
name=SyncThread:0, state=WAITING, group=TGRP-TestAuthenticationFramework]   
  at sun.misc.Unsafe.park(Native Method) at

[jira] [Reopened] (SOLR-8743) Data loss on shard recovery and leader election

2016-02-27 Thread JIRA


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

Jan Høydahl reopened SOLR-8743:
---

Reopening myself, as I probably jumped to conclusions, not paying enough 
attention to the details in steps 5 & 6. Sorry for that. Will let someone with 
deeper detail insight in this area make the call for proper resolution.

> Data loss on shard recovery and leader election
> ---
>
> Key: SOLR-8743
> URL: https://issues.apache.org/jira/browse/SOLR-8743
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5
>Reporter: Matt Weber
>
> SolrCloud with 3 external ZK nodes in quorum, 2 data nodes (NodeA and NodeB). 
>  Single collection that has a single shard and a single replica (replication 
> factor 2).  The primary shard is initially on NodeA and the replica on NodeB.
> 1.  Index Doc1 via NodeA
> ./solr/bin/post -c people -d ' name="id">1'
> 2.  Shutdown NodeA, NodeB becomes the primary. Doc1 is searchable.
> 3.  Delete Doc1 and index Doc2 via NodeB.
> ./solr/bin/post -c people -d "1"
> ./solr/bin/post -c people -d ' name="id">2'
> 4.  Shutdown NodeB, no nodes online.  ZK still up.
> 5.  Start NodeA, it remains in "down" status since NodeB is down and it was 
> last seen as the primary.
> 6.  Start NodeB, it comes online in  "down" status.  NodeA is elected leader 
> and sync starts.  Doc2 is gone, Doc1 exists in both shards.



--
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-8743) Data loss on shard recovery and leader election

2016-02-27 Thread JIRA


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

Jan Høydahl commented on SOLR-8743:
---

Marked this as "Not a bug" for now. But then I also recall a recent JIRA (which 
I cannot find now) that talked about waiting for some time to allow the last 
seen leader to come online and thus avoid data loss. You do not mention the 
timing between up/down here. That may perhaps have a say in whether B should be 
allowed to come up and resume as leader or not. Feel free to reopen if you 
still have reason to believe that this is a bug in the election.

> Data loss on shard recovery and leader election
> ---
>
> Key: SOLR-8743
> URL: https://issues.apache.org/jira/browse/SOLR-8743
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5
>Reporter: Matt Weber
>
> SolrCloud with 3 external ZK nodes in quorum, 2 data nodes (NodeA and NodeB). 
>  Single collection that has a single shard and a single replica (replication 
> factor 2).  The primary shard is initially on NodeA and the replica on NodeB.
> 1.  Index Doc1 via NodeA
> ./solr/bin/post -c people -d ' name="id">1'
> 2.  Shutdown NodeA, NodeB becomes the primary. Doc1 is searchable.
> 3.  Delete Doc1 and index Doc2 via NodeB.
> ./solr/bin/post -c people -d "1"
> ./solr/bin/post -c people -d ' name="id">2'
> 4.  Shutdown NodeB, no nodes online.  ZK still up.
> 5.  Start NodeA, it remains in "down" status since NodeB is down and it was 
> last seen as the primary.
> 6.  Start NodeB, it comes online in  "down" status.  NodeA is elected leader 
> and sync starts.  Doc2 is gone, Doc1 exists in both shards.



--
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-8671) Date statistics: make "sum" a double instead of a long/date

2016-02-27 Thread JIRA


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

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

Hmmm, for some reason the commit didn't make it to the Jira, maybe because I 
used a colon in the commit message.
{noformat}
commit ae4d77ae488fe3c2edf0f9477d843e2433a07a7c
Author: Tomás Fernández Löbbe 
Date:   Sat Feb 27 14:02:30 2016 -0800

SOLR-8671: Date statistics: make "sum" a double instead of a long/date
{noformat}

> Date statistics: make "sum" a double instead of a long/date
> ---
>
> Key: SOLR-8671
> URL: https://issues.apache.org/jira/browse/SOLR-8671
> Project: Solr
>  Issue Type: Improvement
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Fix For: master
>
> Attachments: 0001-change-date-sum-to-double.patch
>
>
> Currently {{DateStatsValues#sum}} is defined as long, and returned as a date. 
> This has two problems: It overflows (with ~6 million values), and the return 
> value can be a date like {{122366-06-12T21:06:06Z}}. 
> I think we should just change this stat to a double. See SOLR-8420.
> I think we can change this only in master, since it will break backward 
> compatibility.



--
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] [Resolved] (SOLR-8743) Data loss on shard recovery and leader election

2016-02-27 Thread JIRA


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

Jan Høydahl resolved SOLR-8743.
---
Resolution: Not A Bug

> Data loss on shard recovery and leader election
> ---
>
> Key: SOLR-8743
> URL: https://issues.apache.org/jira/browse/SOLR-8743
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5
>Reporter: Matt Weber
>
> SolrCloud with 3 external ZK nodes in quorum, 2 data nodes (NodeA and NodeB). 
>  Single collection that has a single shard and a single replica (replication 
> factor 2).  The primary shard is initially on NodeA and the replica on NodeB.
> 1.  Index Doc1 via NodeA
> ./solr/bin/post -c people -d ' name="id">1'
> 2.  Shutdown NodeA, NodeB becomes the primary. Doc1 is searchable.
> 3.  Delete Doc1 and index Doc2 via NodeB.
> ./solr/bin/post -c people -d "1"
> ./solr/bin/post -c people -d ' name="id">2'
> 4.  Shutdown NodeB, no nodes online.  ZK still up.
> 5.  Start NodeA, it remains in "down" status since NodeB is down and it was 
> last seen as the primary.
> 6.  Start NodeB, it comes online in  "down" status.  NodeA is elected leader 
> and sync starts.  Doc2 is gone, Doc1 exists in both shards.



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

2016-02-27 Thread Apache Jenkins Server

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

51 tests failed.
FAILED:  org.apache.solr.TestDistributedMissingSort.test

Error Message:
IOException occured when talking to server at: 
https://127.0.0.1:57014/x_elq/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:57014/x_elq/collection1
at 
__randomizedtesting.SeedInfo.seed([F1434805F134C4C2:791777DF5FC8A93A]: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:551)
at 
org.apache.solr.TestDistributedMissingSort.index(TestDistributedMissingSort.java:48)
at 
org.apache.solr.TestDistributedMissingSort.test(TestDistributedMissingSort.java:42)
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 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1022)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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

[jira] [Commented] (SOLR-8743) Data loss on shard recovery and leader election

2016-02-27 Thread JIRA


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

Jan Høydahl commented on SOLR-8743:
---

*This is expected and by design*
What you have here is two failures in a row, first node A fails, then node B 
fails.
If your requirement is to handle one failed node, then two replicas is 
sufficient.
But if your requirement is to handle two failures at the same time, you need to 
design for N+2 redundancy, i.e. three replicas.

So the real bug here is not in Solr, but in the architect's translation of the 
customers requirements into a too weak SolrCloud cluster.

> Data loss on shard recovery and leader election
> ---
>
> Key: SOLR-8743
> URL: https://issues.apache.org/jira/browse/SOLR-8743
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5
>Reporter: Matt Weber
>
> SolrCloud with 3 external ZK nodes in quorum, 2 data nodes (NodeA and NodeB). 
>  Single collection that has a single shard and a single replica (replication 
> factor 2).  The primary shard is initially on NodeA and the replica on NodeB.
> 1.  Index Doc1 via NodeA
> ./solr/bin/post -c people -d ' name="id">1'
> 2.  Shutdown NodeA, NodeB becomes the primary. Doc1 is searchable.
> 3.  Delete Doc1 and index Doc2 via NodeB.
> ./solr/bin/post -c people -d "1"
> ./solr/bin/post -c people -d ' name="id">2'
> 4.  Shutdown NodeB, no nodes online.  ZK still up.
> 5.  Start NodeA, it remains in "down" status since NodeB is down and it was 
> last seen as the primary.
> 6.  Start NodeB, it comes online in  "down" status.  NodeA is elected leader 
> and sync starts.  Doc2 is gone, Doc1 exists in both shards.



--
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-8741) Json Facet API, numBuckets not returning real number of buckets.

2016-02-27 Thread Yonik Seeley (JIRA)


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

Yonik Seeley commented on SOLR-8741:


IIRC numBuckets is using the same estimation algorithm used for "unique" 
described here: http://yonik.com/solr-count-distinct/
before hyperloglog got added.

We should prob add some way to use hll for numBuckets as well, but for now you 
may be able to work around by using hll directly yourself.

Example:
{code}
json.facet={
  numCat:"hll(cat)",
  categories: {
type : terms,
field : cat
  }
}'
{code}

That should work for the common case, but not for other cases like mincount=N 
(where N>1) for example, or for other domain switching techniques like block 
join.

> Json Facet API, numBuckets not returning real number of buckets.
> 
>
> Key: SOLR-8741
> URL: https://issues.apache.org/jira/browse/SOLR-8741
> Project: Solr
>  Issue Type: Bug
>Reporter: Pablo Anzorena
>
> Hi, using the json facet api I realized that the numBuckets is wrong. It is 
> not returning the right number of buckets. I have a dimension which 
> numBuckets says it has 1340, but when retrieving all the results it brings 
> 988. 
> FYI the field is of type string.
> Thanks.



--
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-8097) Implement a builder pattern for constructing a Solrj client

2016-02-27 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski updated SOLR-8097:
--
Attachment: SOLR-8097.patch

Puts patch on top of latest trunk/master.  Fixes some of Anshum's concerns.  
Still needs tests, fixes based on comments above before it's ready for another 
review.  But I wanted to push up the changes I have so far at least.

> Implement a builder pattern for constructing a Solrj client
> ---
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Hrishikesh Gadre
>Assignee: Anshum Gupta
>Priority: Minor
> Attachments: SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors 
> as follows,
> public CloudSolrClient(String zkHost) 
> public CloudSolrClient(String zkHost, HttpClient httpClient) 
> public CloudSolrClient(Collection zkHosts, String chroot)
> public CloudSolrClient(Collection zkHosts, String chroot, HttpClient 
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient 
> httpClient)
> It is kind of problematic while introducing an additional parameters (since 
> we need to introduce additional constructors). Instead it will be helpful to 
> provide SolrClient Builder which can provide either default values or support 
> overriding specific parameter. 



--
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-8097) Implement a builder pattern for constructing a Solrj client

2016-02-27 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski edited comment on SOLR-8097 at 2/27/16 10:45 PM:
-

So, looking close at these builder classes, I'm not sure that either an 
abstract-class, or an interface approach will allow these methods to be shared 
the way we want.

In a nutshell, the problem is that each builder type returns itself, so that 
calls can be chained.  Setters inherited from an abstract-class/interface 
return the type of that abstract interface, which only has a small subset of 
the methods of the implementation.  This really limits how calls can be chained.

The explanation above seems a little, well, abstract when I re-read it, so 
maybe an example will clarify what I'm trying to say.  Consider:

{code}
abstract class FooBasedBuilder {
public FooBasedBuilder withFoo(Foo foo) { ... return this;}
public abstract Bar build();
}

class BarBuilder extends FooBasedBuilder {
public BarBuilder withBoo(Boo boo) { ... return this; }
public Bar build() {...}
}

// WORKS!
new BarBuilder()
.withBoo(...)  //returns BarBuilder
.withFoo(...)  // BarBuilder has a withFoo() method, so this works.
.build()

// ERROR!
new BarBuilder()
.withFoo(...)  // returns FooBuilder reference
.withBoo(...)  // FooBuilder type doesn't know about withBar(), so this is 
a compilation error!
{code}

As the examples above show, with the abstract-class-for-code-sharing design, 
the order that setters are called in matters. Once a parent class method is 
called, subclass methods can't be chained on.

Maybe there's a way around this, but I haven't been able to find one after 
spending an hour or so racking my brains about it.  With this in mind, if no 
one can find an alternative, I'm going to go back to removing the code-sharing 
portion of this patch, as much as that sucks.

If no one has any better ideas, I'm hoping to push up a patch with this change 
(and the others Anshum suggested above).


was (Author: gerlowskija):
So, looking close at these builder classes, I'm not sure that either an 
abstract-class, or an interface approach will allow these methods to be shared 
the way we want.

In a nutshell, the problem is that each builder type returns itself, so that 
calls can be chained.  Setters inherited from an abstract-class/interface 
return the type of that abstract interface, which only has a small subset of 
the methods of the implementation.  This really limits how calls can be chained.

The explanation above seems a little, well, abstract when I re-read it, so 
maybe an example will clarify what I'm trying to say.  Consider:

{code}
abstract class FooBasedBuilder {
public FooBasedBuilder withFoo(Foo foo) { ... return this;}
public abstract Bar build();
}

class BarBuilder extends FooBasedBuilder {
public BarBuilder withBoo(Boo boo) { ... return this; }
public Bar build() {...}
}

// WORKS!
new BarBuilder()
.withBoo(...)  //returns BarBuilder
.withFoo(...)  // BarBuilder has a withFoo() method, so this works.
.build()

// ERROR!
new BarBuilder()
.withFoo(...)  // returns FooBuilder reference
.withBoo(...)  // FooBuilder type doesn't know about withBar(), so this is 
a compilation error!
{code}

As the examples above show, with the abstract-class-for-code-sharing design, 
the order that setters are called in matters. Once a parent class method is 
called, subclass methods can't be chained on.

Maybe there's a way around this, but I haven't been able to find one after 
spending an hour or so racking my brains about it.  With this in mind, if no 
one can find an alternative, I'm going to go back to removing the code-sharing 
portion of this patch, as much as that sucks.

> Implement a builder pattern for constructing a Solrj client
> ---
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Hrishikesh Gadre
>Assignee: Anshum Gupta
>Priority: Minor
> Attachments: SOLR-8097.patch, SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors 
> as follows,
> public CloudSolrClient(String zkHost) 
> public CloudSolrClient(String zkHost, HttpClient httpClient) 
> public CloudSolrClient(Collection zkHosts, String chroot)
> public CloudSolrClient(Collection zkHosts, String chroot, HttpClient 
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient 
> httpClient)
> It is kind of problematic while introducing an additional parameters (since 
> we need

[jira] [Commented] (SOLR-8097) Implement a builder pattern for constructing a Solrj client

2016-02-27 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski commented on SOLR-8097:
---

So, looking close at these builder classes, I'm not sure that either an 
abstract-class, or an interface approach will allow these methods to be shared 
the way we want.

In a nutshell, the problem is that each builder type returns itself, so that 
calls can be chained.  Setters inherited from an abstract-class/interface 
return the type of that abstract interface, which only has a small subset of 
the methods of the implementation.  This really limits how calls can be chained.

The explanation above seems a little, well, abstract when I re-read it, so 
maybe an example will clarify what I'm trying to say.  Consider:

{code}
abstract class FooBasedBuilder {
public FooBasedBuilder withFoo(Foo foo) { ... return this;}
public abstract Bar build();
}

class BarBuilder extends FooBasedBuilder {
public BarBuilder withBoo(Boo boo) { ... return this; }
public Bar build() {...}
}

// WORKS!
new BarBuilder()
.withBoo(...)  //returns BarBuilder
.withFoo(...)  // BarBuilder has a withFoo() method, so this works.
.build()

// ERROR!
new BarBuilder()
.withFoo(...)  // returns FooBuilder reference
.withBoo(...)  // FooBuilder type doesn't know about withBar(), so this is 
a compilation error!
{code}

As the examples above show, with the abstract-class-for-code-sharing design, 
the order that setters are called in matters. Once a parent class method is 
called, subclass methods can't be chained on.

Maybe there's a way around this, but I haven't been able to find one after 
spending an hour or so racking my brains about it.  With this in mind, if no 
one can find an alternative, I'm going to go back to removing the code-sharing 
portion of this patch, as much as that sucks.

> Implement a builder pattern for constructing a Solrj client
> ---
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Hrishikesh Gadre
>Assignee: Anshum Gupta
>Priority: Minor
> Attachments: SOLR-8097.patch, SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors 
> as follows,
> public CloudSolrClient(String zkHost) 
> public CloudSolrClient(String zkHost, HttpClient httpClient) 
> public CloudSolrClient(Collection zkHosts, String chroot)
> public CloudSolrClient(Collection zkHosts, String chroot, HttpClient 
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient 
> httpClient)
> It is kind of problematic while introducing an additional parameters (since 
> we need to introduce additional constructors). Instead it will be helpful to 
> provide SolrClient Builder which can provide either default values or support 
> overriding specific parameter. 



--
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-8110) Start enforcing field naming recomendations in next X.0 release?

2016-02-27 Thread JIRA


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

Jan Høydahl commented on SOLR-8110:
---

I buy Yonik's arguments for reserving both dot and dash for future cool stuff. 
When I argued for allowing these earlier it was as a compromise between chaos 
(today) and pain (every Solr application needing a rewrite).

Perhaps we could define three modes for users to choose between, with pros/cons 
documented: 
"safe" - {{\[a-zA-Z0-9_\]}} only, guaranteed future proof, full SQL, script 
support
"moderate" - safe + dash, dot, dollar and perhaps national unicode letters
"legacy" - no restrictions - only for easy back compat - will go away in 7.0

In 6.0, "moderate" would be the default, use of non-safe chars will be logged, 
and users can revert to "legacy" if they wish, but will be aware of what 
functionality they then sacrifice. In 7.0, "safe" could be made the default, 
and allow people to revert to "moderate" but take away "legacy". This will 
allow certain features to "bail out" with exception if in a mode that is known 
to cause problems.

> 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
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> 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

[jira] [Commented] (SOLR-8721) Add Solr version to debug response

2016-02-27 Thread Alexandre Rafalovitch (JIRA)


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

Alexandre Rafalovitch commented on SOLR-8721:
-

Is there a serious value in the impl-version string?

On the other hand, is there a value is sending what lucene version the 
solrconfig.xml file pegs the core at?

> Add Solr version to debug response
> --
>
> Key: SOLR-8721
> URL: https://issues.apache.org/jira/browse/SOLR-8721
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
>
> In troubleshooting customer issues, often they'll send send a Solr debug=true 
> output.  It'd be helpful to have more information, such as the Solr version 
> number, in the response.



--
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-Windows (64bit/jdk1.8.0_72) - Build # 5650 - Failure!

2016-02-27 Thread Policeman Jenkins Server

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

29 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testSolrJAPICalls

Error Message:
IOException occured when talking to server at: http://127.0.0.1:50960

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:50960
at 
__randomizedtesting.SeedInfo.seed([401BABCC3659DCDC:187F27AD30337408]: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.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testSolrJAPICalls(CollectionsAPIAsyncDistributedZkTest.java:57)
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:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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

[jira] [Commented] (SOLR-8671) Date statistics: make "sum" a double instead of a long/date

2016-02-27 Thread JIRA


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

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

I added this change: 
{noformat}
-return Math.sqrt(((count * sumOfSquares) - (sum * (double)sum))
+return Math.sqrt(((count * sumOfSquares) - (sum * sum))
{noformat}
since sum is now a double

> Date statistics: make "sum" a double instead of a long/date
> ---
>
> Key: SOLR-8671
> URL: https://issues.apache.org/jira/browse/SOLR-8671
> Project: Solr
>  Issue Type: Improvement
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Fix For: master
>
> Attachments: 0001-change-date-sum-to-double.patch
>
>
> Currently {{DateStatsValues#sum}} is defined as long, and returned as a date. 
> This has two problems: It overflows (with ~6 million values), and the return 
> value can be a date like {{122366-06-12T21:06:06Z}}. 
> I think we should just change this stat to a double. See SOLR-8420.
> I think we can change this only in master, since it will break backward 
> compatibility.



--
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-8097) Implement a builder pattern for constructing a Solrj client

2016-02-27 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski edited comment on SOLR-8097 at 2/27/16 9:40 PM:


Thanks for the review Anshum.  Sorry it took me a few days to get back to this. 
 Wanted to respond to your comments:

- re: {{updateLeadersOnly}}.  Done; I've changed the name back to 
{{updatesToLeaders}}.
- re: import cleanup.  Done.
- re: Javadoc return tag.  Didn't quite understand your comment.  Looking 
through the patch, I couldn't find the @return tag anywhere.  Can you clarify 
what you meant please?
- re: CUSC change being unrelated.  I think this change is necessary.  The CUSC 
ctor that the change occurs in is now called from CUSCB (CUSCBuilder), which 
may or may not have a real ExecutorService to pass in.  Since CUSC needs an 
ExecutorService, I changed to ctor to create its own if the param is null.  
Hence those lines in the patch.  I'm sure there's other ways to solve this 
problem if there's something you don't like about those lines, but they are 
related/required for the patch as it is now.
- re: BRP is now used as default in HSC/LBHSC.  Looking at these classes, the 
ctors that don't take in a ResponseParser create their own BinaryResponseParser 
to take its place.  So BRP is already the default here.  I had to make this 
explicit in the ctors that take a ResponseParser, due to the same dynamic 
mentioned in the bullet point above (That is, the ctor is now called from a 
builder, where responseParser may or may not have actually been set).  So I 
think this change is also related/required for this patch.




was (Author: gerlowskija):
Thanks for the review Anshum.  Sorry it took me a few days to get back to this. 
 Wanted to respond to your comments:

- re: {{updateLeadersOnly}}.  Done; I've changed the name back to 
{{updatesToLeaders}}.
- re: import cleanup.  Done.
- re: Javadoc return tag.  Didn't quite understand your comment.  Looking 
through the patch, I couldn't find the @return tag anywhere.  Can you clarify 
what you meant please?
- re: CUSC change being unrelated.  I think this change is necessary.  The CUSC 
ctor that the change occurs in is now called from CUSCB (CUSCBuilder), which 
may or may not have a real ExecutorService to pass in.  Since CUSC needs an 
ExecutorService, I changed to ctor to create its own if the param is null.  
Hence those lines in the patch.  I'm sure there's other ways to solve this 
problem if there's something you don't like about those lines, but they are 
related/required for the patch as it is now.
- re: BRP is now used as default in HSC/LBHSC.  Looking at these classes, the 
ctors don't take in a ResponseParser create their own BinaryResponseParser.  So 
BRP is already the default here.  I had to make this explicit in the ctors that 
take a ResponseParser, due to the same dynamic mentioned in the bullet point 
above (That is, the ctor is now called from a builder, where responseParser may 
or may not have actually been set).  So I think this change is also 
related/required for this patch.



> Implement a builder pattern for constructing a Solrj client
> ---
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Hrishikesh Gadre
>Assignee: Anshum Gupta
>Priority: Minor
> Attachments: SOLR-8097.patch, SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors 
> as follows,
> public CloudSolrClient(String zkHost) 
> public CloudSolrClient(String zkHost, HttpClient httpClient) 
> public CloudSolrClient(Collection zkHosts, String chroot)
> public CloudSolrClient(Collection zkHosts, String chroot, HttpClient 
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient 
> httpClient)
> It is kind of problematic while introducing an additional parameters (since 
> we need to introduce additional constructors). Instead it will be helpful to 
> provide SolrClient Builder which can provide either default values or support 
> overriding specific parameter. 



--
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+106) - Build # 145 - Failure!

2016-02-27 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/145/
Java: 64bit/jdk-9-ea+106 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.lucene.codecs.memory.TestMemoryPostingsFormat.testDocsAndFreqsAndPositionsAndOffsetsAndPayloads

Error Message:
Captured an uncaught exception in thread: Thread[id=627, name=Thread-605, 
state=RUNNABLE, group=TGRP-TestMemoryPostingsFormat]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=627, name=Thread-605, state=RUNNABLE, 
group=TGRP-TestMemoryPostingsFormat]
Caused by: java.lang.RuntimeException: java.lang.IllegalArgumentException: 
source=3 is out of bounds (maxState is 2)
at __randomizedtesting.SeedInfo.seed([9326B2672012136C]:0)
at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1005)
Caused by: java.lang.IllegalArgumentException: source=3 is out of bounds 
(maxState is 2)
at 
org.apache.lucene.util.automaton.Automaton.addTransition(Automaton.java:167)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:245)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:515)
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:1166)
at 
org.apache.lucene.index.RandomPostingsTester.access$000(RandomPostingsTester.java:62)
at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1003)




Build Log:
[...truncated 6381 lines...]
   [junit4] Suite: org.apache.lucene.codecs.memory.TestMemoryPostingsFormat
   [junit4]   2> guov 27, 2016 4:12:06 EAHKETBEAIVET 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> WARNING: Uncaught exception in thread: 
Thread[Thread-605,5,TGRP-TestMemoryPostingsFormat]
   [junit4]   2> java.lang.RuntimeException: 
java.lang.IllegalArgumentException: source=3 is out of bounds (maxState is 2)
   [junit4]   2>at 
__randomizedtesting.SeedInfo.seed([9326B2672012136C]:0)
   [junit4]   2>at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1005)
   [junit4]   2> Caused by: java.lang.IllegalArgumentException: source=3 is out 
of bounds (maxState is 2)
   [junit4]   2>at 
org.apache.lucene.util.automaton.Automaton.addTransition(Automaton.java:167)
   [junit4]   2>at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:245)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:515)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
   [junit4]   2>at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomSingleAutomaton(AutomatonTestUtil.java:262)
   [junit4]   2>at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomAutomaton(AutomatonTestUtil.java:276)
   [junit4]   2>at 
org.apache.lucene.index.RandomPostingsTester.testTermsOneThread(RandomPostingsTester.java:1166)
   [junit4]   2>at 
org.apache.lucene.index.RandomPostingsTester.access$000(RandomPostingsTester.java:62)
   [junit4]   2>at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1003)
   [junit4]   2> 
   [junit4]   2> guov 27, 2016 4:12:06 EAHKETBEAIVET 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> WARNING: Uncaught exception in thread: 
Thread[Thread-606,5,TGRP-TestMemoryPostingsFormat]
   [junit4]   2> java.lang.RuntimeException: 
java.lang.ArrayIndexOutOfBoundsException: 5
   [junit4]   2>at 
__randomizedtesting.SeedInfo.seed([9326B2672012136C]:0)
   [junit4]   2>at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1005)
   [junit4]   2> Caused by: java.lang.ArrayIndexOutOfBoundsException: 5
   [junit4]   2>at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:515)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)

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

2016-02-27 Thread Policeman Jenkins Server

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

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

Error Message:
Captured an uncaught exception in thread: Thread[id=3840, 
name=testExecutor-2061-thread-4, state=RUNNABLE, 
group=TGRP-UnloadDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=3840, name=testExecutor-2061-thread-4, 
state=RUNNABLE, group=TGRP-UnloadDistributedZkTest]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:51876
at __randomizedtesting.SeedInfo.seed([AB86964C70C8349D]:0)
at 
org.apache.solr.cloud.BasicDistributedZkTest$1.run(BasicDistributedZkTest.java:586)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:231)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.solr.client.solrj.SolrServerException: Timeout occured 
while waiting response from server at: http://127.0.0.1:51876
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:588)
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.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.BasicDistributedZkTest$1.run(BasicDistributedZkTest.java:584)
... 4 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
at 
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at 
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
at 
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:685)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:487)
at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:482)
... 8 more




Build Log:
[...truncated 10923 lines...]
   [junit4] Suite: org.apache.solr.cloud.UnloadDistributedZkTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.UnloadDistributedZkTest_AB86964C70C8349D-001/init-core-data-001
   [junit4]   2> 420282 INFO  
(SUITE-UnloadDistributedZkTest-seed#[AB86964C70C8349D]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 420284 INFO  
(TEST-UnloadDistributedZkTest.test-seed#[AB86964C70C8349D]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 420287 INFO  (Thread-1436) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 420287 INFO  (Thread-1436) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 420387 INFO

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

2016-02-27 Thread Gus Heck (JIRA)


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

Gus Heck commented on SOLR-8110:


So perhaps a quoting Identifiers JIRA ticket that this is blocked by?

> 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
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> 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

[jira] [Comment Edited] (SOLR-7516) Improve javadocs for JavaBinCodec, ObjectResolver and enforce the single-usage policy

2016-02-27 Thread Benoit Vanalderweireldt (JIRA)


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

Benoit Vanalderweireldt edited comment on SOLR-7516 at 2/27/16 7:50 PM:


I would love to step in and improve the ObjectResolver (javadoc + assertion 
errors)


was (Author: b.vanalderweireldt):
I would love to step in and improve the ObjectResolver

> Improve javadocs for JavaBinCodec, ObjectResolver and enforce the 
> single-usage policy
> -
>
> Key: SOLR-7516
> URL: https://issues.apache.org/jira/browse/SOLR-7516
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
>  Labels: difficulty-easy, newdev
> Fix For: 5.2, master
>
> Attachments: SOLR-7516.patch
>
>
> The Javadocs of this class can use some improvements. It doesn't adequately 
> describe the purpose of the ObjectResolver. Also, since it says that this 
> object should be used only once for marshalling or unmarshalling operation, 
> we should enforce it in code via asserts and/or exceptions.



--
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-7516) Improve javadocs for JavaBinCodec, ObjectResolver and enforce the single-usage policy

2016-02-27 Thread Benoit Vanalderweireldt (JIRA)


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

Benoit Vanalderweireldt commented on SOLR-7516:
---

I would love to step in and improve the ObjectResolver

> Improve javadocs for JavaBinCodec, ObjectResolver and enforce the 
> single-usage policy
> -
>
> Key: SOLR-7516
> URL: https://issues.apache.org/jira/browse/SOLR-7516
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
>  Labels: difficulty-easy, newdev
> Fix For: 5.2, master
>
> Attachments: SOLR-7516.patch
>
>
> The Javadocs of this class can use some improvements. It doesn't adequately 
> describe the purpose of the ObjectResolver. Also, since it says that this 
> object should be used only once for marshalling or unmarshalling operation, 
> we should enforce it in code via asserts and/or exceptions.



--
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-8110) Start enforcing field naming recomendations in next X.0 release?

2016-02-27 Thread Jack Krupansky (JIRA)


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

Jack Krupansky commented on SOLR-8110:
--

I can't recall any explicit statement on case sensitivity, although I would 
imagine that the existing "anything goes" model would default to 
case-sensitive. Personally, I would prefer case-insensitive. I can't recall a 
schema in which case-sensitive field names were used, while case mistakes are 
not uncommon.

> 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
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> 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-trunk-Linux (64bit/jdk-9-ea+106) - Build # 16026 - Still Failing!

2016-02-27 Thread Policeman Jenkins Server

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

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

Error Message:
6

Stack Trace:
java.lang.ArrayIndexOutOfBoundsException: 6
at 
__randomizedtesting.SeedInfo.seed([B363459E785D0409:9128F1CAEBD8843C]: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:111)
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 746 lines...]
   [junit4] Suite: org.apache.lucene.util.TestQueryBuilder
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestQueryBuilder 
-Dtests.method=testPhraseQueryPositionIncrements -Dtests.seed=B363459E785D0409 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=fr-LU 
-Dtests.timezone=Pacific/Tahiti -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4]

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

2016-02-27 Thread Apache Jenkins Server

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

1 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_B1C5C348F3EE1A9F-001/solr-instance-010/./collection1/data/index.20160227123855449,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_B1C5C348F3EE1A9F-001/solr-instance-010/./collection1/data,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_B1C5C348F3EE1A9F-001/solr-instance-010/./collection1/data/index.20160227123855364]
 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_B1C5C348F3EE1A9F-001/solr-instance-010/./collection1/data/index.20160227123855449,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_B1C5C348F3EE1A9F-001/solr-instance-010/./collection1/data,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_B1C5C348F3EE1A9F-001/solr-instance-010/./collection1/data/index.20160227123855364]
 expected:<2> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([B1C5C348F3EE1A9F:46B62D103506B579]: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

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

2016-02-27 Thread Jack Krupansky (JIRA)


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

Jack Krupansky commented on SOLR-8110:
--

Dollar sign is permitted in Java identifier, including at the start. As per the 
Java Spec, "The "Java letters" include uppercase and lowercase ASCII Latin 
letters A-Z (\u0041-\u005a), and a-z (\u0061-\u007a), and, for historical 
reasons, the ASCII underscore (_, or \u005f) and dollar sign ($, or \u0024)." 
It goes on to say that "The $ character should be used only in mechanically 
generated source code or, rarely, to access pre-existing names on legacy 
systems."

See:
https://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.8

If anything, I had been assuming that we were proposing a superset of Java 
identifiers (hyphen, dot as part of name.)

I'm not positive whether there might be any conflict with parameter 
substitution for dollar sign.


> 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
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> 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] Lucene-Solr-5.5-Solaris (64bit/jdk1.8.0) - Build # 17 - Still Failing!

2016-02-27 Thread Policeman Jenkins Server

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

1 tests failed.
FAILED:  
org.apache.lucene.index.TestExitableDirectoryReader.testExitableFilterIndexReader

Error Message:
The request took too long to iterate over terms. Timeout: timeoutAt: 
1040199529198899 (System.nanoTime(): 1040199539471335), 
TermsEnum=org.apache.lucene.codecs.blockterms.BlockTermsReader$FieldReader$SegmentTermsEnum@7093c8e3

Stack Trace:
org.apache.lucene.index.ExitableDirectoryReader$ExitingReaderException: The 
request took too long to iterate over terms. Timeout: timeoutAt: 
1040199529198899 (System.nanoTime(): 1040199539471335), 
TermsEnum=org.apache.lucene.codecs.blockterms.BlockTermsReader$FieldReader$SegmentTermsEnum@7093c8e3
at 
__randomizedtesting.SeedInfo.seed([7144CD6343DB6D8F:C92160222801E476]:0)
at 
org.apache.lucene.index.ExitableDirectoryReader$ExitableTermsEnum.checkAndThrow(ExitableDirectoryReader.java:167)
at 
org.apache.lucene.index.ExitableDirectoryReader$ExitableTermsEnum.(ExitableDirectoryReader.java:157)
at 
org.apache.lucene.index.ExitableDirectoryReader$ExitableTerms.iterator(ExitableDirectoryReader.java:141)
at 
org.apache.lucene.index.FilterLeafReader$FilterTerms.iterator(FilterLeafReader.java:113)
at 
org.apache.lucene.index.TestExitableDirectoryReader$TestReader$TestTerms.iterator(TestExitableDirectoryReader.java:58)
at org.apache.lucene.index.Terms.intersect(Terms.java:72)
at 
org.apache.lucene.util.automaton.CompiledAutomaton.getTermsEnum(CompiledAutomaton.java:336)
at 
org.apache.lucene.search.AutomatonQuery.getTermsEnum(AutomatonQuery.java:108)
at 
org.apache.lucene.search.MultiTermQuery.getTermsEnum(MultiTermQuery.java:318)
at 
org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.rewrite(MultiTermQueryConstantScoreWrapper.java:146)
at 
org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.bulkScorer(MultiTermQueryConstantScoreWrapper.java:199)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:818)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:535)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:744)
at 
org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:460)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:489)
at 
org.apache.lucene.index.TestExitableDirectoryReader.testExitableFilterIndexReader(TestExitableDirectoryReader.java:127)
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.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

[jira] [Commented] (SOLR-8629) When a prospective leader attempts to sync with it's shard, we should only fail the sync due to peer sync, not necessarily other exceptions.

2016-02-27 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-8629:
---

This may be as simple as adding code 500 as a success on peersync like we 
currently do on connect exceptions. My worry is the same as those exceptions 
though - it may be a very temporary situation, and the affected node may be the 
best leader candidate.

That is why I've been thinking about SOLR-8753. It would be nice to allow a 
couple of retries of the possible leaders over time in these situations. I 
think that may be tricky to do nicely with the current code though.

> When a prospective leader attempts to sync with it's shard, we should only 
> fail the sync due to peer sync, not necessarily other exceptions.
> 
>
> Key: SOLR-8629
> URL: https://issues.apache.org/jira/browse/SOLR-8629
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>
> Otherwise, one screwed up replica can prevent a leader even if there are 100 
> other good replicas.



--
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-8097) Implement a builder pattern for constructing a Solrj client

2016-02-27 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski commented on SOLR-8097:
---

Thanks for the review Anshum.  Sorry it took me a few days to get back to this. 
 Wanted to respond to your comments:

- re: {{updateLeadersOnly}}.  Done; I've changed the name back to 
{{updatesToLeaders}}.
- re: import cleanup.  Done.
- re: Javadoc return tag.  Didn't quite understand your comment.  Looking 
through the patch, I couldn't find the @return tag anywhere.  Can you clarify 
what you meant please?
- re: CUSC change being unrelated.  I think this change is necessary.  The CUSC 
ctor that the change occurs in is now called from CUSCB (CUSCBuilder), which 
may or may not have a real ExecutorService to pass in.  Since CUSC needs an 
ExecutorService, I changed to ctor to create its own if the param is null.  
Hence those lines in the patch.  I'm sure there's other ways to solve this 
problem if there's something you don't like about those lines, but they are 
related/required for the patch as it is now.
-re: BRP is now used as default in HSC/LBHSC.  Looking at these classes, the 
ctors don't take in a ResponseParser create their own BinaryResponseParser.  So 
BRP is already the default here.  I had to make this explicit in the ctors that 
take a ResponseParser, due to the same dynamic mentioned in the bullet point 
above (That is, the ctor is now called from a builder, where responseParser may 
or may not have actually been set).  So I think this change is also 
related/required for this patch.



> Implement a builder pattern for constructing a Solrj client
> ---
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Hrishikesh Gadre
>Assignee: Anshum Gupta
>Priority: Minor
> Attachments: SOLR-8097.patch, SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors 
> as follows,
> public CloudSolrClient(String zkHost) 
> public CloudSolrClient(String zkHost, HttpClient httpClient) 
> public CloudSolrClient(Collection zkHosts, String chroot)
> public CloudSolrClient(Collection zkHosts, String chroot, HttpClient 
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient 
> httpClient)
> It is kind of problematic while introducing an additional parameters (since 
> we need to introduce additional constructors). Instead it will be helpful to 
> provide SolrClient Builder which can provide either default values or support 
> overriding specific parameter. 



--
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-8097) Implement a builder pattern for constructing a Solrj client

2016-02-27 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski edited comment on SOLR-8097 at 2/27/16 6:40 PM:


Thanks for the review Anshum.  Sorry it took me a few days to get back to this. 
 Wanted to respond to your comments:

- re: {{updateLeadersOnly}}.  Done; I've changed the name back to 
{{updatesToLeaders}}.
- re: import cleanup.  Done.
- re: Javadoc return tag.  Didn't quite understand your comment.  Looking 
through the patch, I couldn't find the @return tag anywhere.  Can you clarify 
what you meant please?
- re: CUSC change being unrelated.  I think this change is necessary.  The CUSC 
ctor that the change occurs in is now called from CUSCB (CUSCBuilder), which 
may or may not have a real ExecutorService to pass in.  Since CUSC needs an 
ExecutorService, I changed to ctor to create its own if the param is null.  
Hence those lines in the patch.  I'm sure there's other ways to solve this 
problem if there's something you don't like about those lines, but they are 
related/required for the patch as it is now.
- re: BRP is now used as default in HSC/LBHSC.  Looking at these classes, the 
ctors don't take in a ResponseParser create their own BinaryResponseParser.  So 
BRP is already the default here.  I had to make this explicit in the ctors that 
take a ResponseParser, due to the same dynamic mentioned in the bullet point 
above (That is, the ctor is now called from a builder, where responseParser may 
or may not have actually been set).  So I think this change is also 
related/required for this patch.




was (Author: gerlowskija):
Thanks for the review Anshum.  Sorry it took me a few days to get back to this. 
 Wanted to respond to your comments:

- re: {{updateLeadersOnly}}.  Done; I've changed the name back to 
{{updatesToLeaders}}.
- re: import cleanup.  Done.
- re: Javadoc return tag.  Didn't quite understand your comment.  Looking 
through the patch, I couldn't find the @return tag anywhere.  Can you clarify 
what you meant please?
- re: CUSC change being unrelated.  I think this change is necessary.  The CUSC 
ctor that the change occurs in is now called from CUSCB (CUSCBuilder), which 
may or may not have a real ExecutorService to pass in.  Since CUSC needs an 
ExecutorService, I changed to ctor to create its own if the param is null.  
Hence those lines in the patch.  I'm sure there's other ways to solve this 
problem if there's something you don't like about those lines, but they are 
related/required for the patch as it is now.
-re: BRP is now used as default in HSC/LBHSC.  Looking at these classes, the 
ctors don't take in a ResponseParser create their own BinaryResponseParser.  So 
BRP is already the default here.  I had to make this explicit in the ctors that 
take a ResponseParser, due to the same dynamic mentioned in the bullet point 
above (That is, the ctor is now called from a builder, where responseParser may 
or may not have actually been set).  So I think this change is also 
related/required for this patch.



> Implement a builder pattern for constructing a Solrj client
> ---
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Hrishikesh Gadre
>Assignee: Anshum Gupta
>Priority: Minor
> Attachments: SOLR-8097.patch, SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors 
> as follows,
> public CloudSolrClient(String zkHost) 
> public CloudSolrClient(String zkHost, HttpClient httpClient) 
> public CloudSolrClient(Collection zkHosts, String chroot)
> public CloudSolrClient(Collection zkHosts, String chroot, HttpClient 
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient 
> httpClient)
> It is kind of problematic while introducing an additional parameters (since 
> we need to introduce additional constructors). Instead it will be helpful to 
> provide SolrClient Builder which can provide either default values or support 
> overriding specific parameter. 



--
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-8110) Start enforcing field naming recomendations in next X.0 release?

2016-02-27 Thread Shawn Heisey (JIRA)


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

Shawn Heisey commented on SOLR-8110:


bq. I doubt there's a ton of people using dollar-signs in their field names

Somebody came into the IRC channel once, using a Solr plugin for some PHP 
software which I can no longer remember, and when they shared the schema that 
came with the plugin, almost every field had at least two dollar signs in the 
name.  I've seen all kinds of weird characters in field names.  Sometimes they 
work, sometimes they don't.


> 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
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> 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

[jira] [Commented] (SOLR-8097) Implement a builder pattern for constructing a Solrj client

2016-02-27 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski commented on SOLR-8097:
---

Gonna revert my different name (updateLeadersOnly) as Anshum initially 
suggested, and keep the name {{updatesToLeaders}} as it is for now.  Maybe the 
name/behavior/Javadocs should change, but I'd rather not touch that in this 
JIRA, as I don't have a great understanding of the background there, and it'd 
take some time to look into that.

If there's still changes regarding that param, I'm happy to do that in a 
separate JIRA/patch if you guys want.

> Implement a builder pattern for constructing a Solrj client
> ---
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Hrishikesh Gadre
>Assignee: Anshum Gupta
>Priority: Minor
> Attachments: SOLR-8097.patch, SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors 
> as follows,
> public CloudSolrClient(String zkHost) 
> public CloudSolrClient(String zkHost, HttpClient httpClient) 
> public CloudSolrClient(Collection zkHosts, String chroot)
> public CloudSolrClient(Collection zkHosts, String chroot, HttpClient 
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient 
> httpClient)
> It is kind of problematic while introducing an additional parameters (since 
> we need to introduce additional constructors). Instead it will be helpful to 
> provide SolrClient Builder which can provide either default values or support 
> overriding specific parameter. 



--
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 # 884 - Still Failing

2016-02-27 Thread Apache Jenkins Server

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.OverseerTest.testExternalClusterStateChangeBehavior

Error Message:
Illegal state, was: down expected:active clusterState:live 
nodes:[]collections:{c1=DocCollection(c1)={   "shards":{"shard1":{   
"parent":null,   "range":null,   "state":"active",   
"replicas":{"core_node1":{   "base_url":"http://127.0.0.1/solr;,
   "node_name":"node1",   "core":"core1",   "roles":"", 
  "state":"down",   "router":{"name":"implicit"}}, 
test=LazyCollectionRef(test)}

Stack Trace:
java.lang.AssertionError: Illegal state, was: down expected:active 
clusterState:live nodes:[]collections:{c1=DocCollection(c1)={
  "shards":{"shard1":{
  "parent":null,
  "range":null,
  "state":"active",
  "replicas":{"core_node1":{
  "base_url":"http://127.0.0.1/solr;,
  "node_name":"node1",
  "core":"core1",
  "roles":"",
  "state":"down",
  "router":{"name":"implicit"}}, test=LazyCollectionRef(test)}
at 
__randomizedtesting.SeedInfo.seed([31D689C6D24391D6:59C88A2A30D3CB98]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.verifyReplicaStatus(AbstractDistribZkTestBase.java:236)
at 
org.apache.solr.cloud.OverseerTest.testExternalClusterStateChangeBehavior(OverseerTest.java:1277)
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

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

2016-02-27 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16025/
Java: 32bit/jdk-9-ea+106 -server -XX:+UseG1GC

37 tests failed.
FAILED:  org.apache.lucene.codecs.autoprefix.TestAutoPrefixPostingsFormat.test

Error Message:
Unable to unmap the mapped buffer: 
MMapIndexInput(path="/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/codecs/test/J1/temp/lucene.codecs.autoprefix.TestAutoPrefixPostingsFormat_4AD4CB7CC8B872A6-001/autoprefix-001/_0_AutoPrefix_0.doc")

Stack Trace:
java.io.IOException: Unable to unmap the mapped buffer: 
MMapIndexInput(path="/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/codecs/test/J1/temp/lucene.codecs.autoprefix.TestAutoPrefixPostingsFormat_4AD4CB7CC8B872A6-001/autoprefix-001/_0_AutoPrefix_0.doc")
at 
__randomizedtesting.SeedInfo.seed([4AD4CB7CC8B872A6:C280F4A666441F5E]:0)
at 
org.apache.lucene.store.MMapDirectory.lambda$initUnmapHack$1(MMapDirectory.java:384)
at 
org.apache.lucene.store.ByteBufferIndexInput.freeBuffer(ByteBufferIndexInput.java:376)
at 
org.apache.lucene.store.ByteBufferIndexInput.close(ByteBufferIndexInput.java:355)
at 
org.apache.lucene.util.LuceneTestCase.slowFileExists(LuceneTestCase.java:2680)
at 
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:732)
at 
org.apache.lucene.codecs.lucene50.Lucene50PostingsReader.(Lucene50PostingsReader.java:81)
at 
org.apache.lucene.codecs.autoprefix.AutoPrefixPostingsFormat.fieldsProducer(AutoPrefixPostingsFormat.java:113)
at 
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:261)
at 
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:341)
at 
org.apache.lucene.index.RandomPostingsTester.buildIndex(RandomPostingsTester.java:680)
at 
org.apache.lucene.index.RandomPostingsTester.testFull(RandomPostingsTester.java:1253)
at 
org.apache.lucene.codecs.autoprefix.TestAutoPrefixPostingsFormat.test(TestAutoPrefixPostingsFormat.java:33)
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

[jira] [Commented] (SOLR-8629) When a prospective leader attempts to sync with it's shard, we should only fail the sync due to peer sync, not necessarily other exceptions.

2016-02-27 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-8629:
---

I think SOLR-8753 will allow us to be a little bit more conservative in some of 
these issues. Right now, even though elections were originally intended to 
retry forever, currently each replica generally only gets one shot at trying to 
be the leader.

> When a prospective leader attempts to sync with it's shard, we should only 
> fail the sync due to peer sync, not necessarily other exceptions.
> 
>
> Key: SOLR-8629
> URL: https://issues.apache.org/jira/browse/SOLR-8629
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>
> Otherwise, one screwed up replica can prevent a leader even if there are 100 
> other good replicas.



--
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-8110) Start enforcing field naming recomendations in next X.0 release?

2016-02-27 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski edited comment on SOLR-8110 at 2/27/16 5:21 PM:


bq. If we expand the set to include what people may have used in the past 
(dashes, dots, etc), that sort of takes us full circle back to the state of 
things today

That's not quite true. Even if we allow all the characters that've been brought 
up by this JIRA (dashes, dots, underscores), this JIRA would still treat many 
others as invalid: slashes, spaces, unicode characters, most of the number-row 
of your keyboard (!@#$%^&()+), etc.

I doubt there's a ton of people using dollar-signs in their field names, but 
anyone who does will probably see some quirky behavior.  And if we can warn 
them (or stop them) up front about that, even for rarely used characters, that 
might still be valuable.


was (Author: gerlowskija):
bq. If we expand the set to include what people may have used in the past 
(dashes, dots, etc), that sort of takes us full circle back to the state of 
things today

That's not quite true. Even if we allow all the characters that've been brought 
up by this JIRA (dashes, dots, underscores), this JIRA would still treat many 
others as invalid: slashes, spaces, unicode characters, most of the number-row 
of your keyboard (!@#$%^&()+), etc.

I doubt there's a ton of people using dollar-signs in their field names, but 
anyone who does will probably see some quirky behavior.  And if we can warn up 
front about that, even for rarely used characters, that might still be valuable.

> 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
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> 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] Lucene-Solr-5.5-MacOSX (64bit/jdk1.8.0) - Build # 17 - Failure!

2016-02-27 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-MacOSX/17/
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([D68CFB8B2DA29FF4:5ED8C451835EF20C]: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:836)
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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 883 - Failure

2016-02-27 Thread Apache Jenkins Server

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

40 tests failed.
FAILED:  org.apache.solr.TestDistributedMissingSort.test

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:54724/fyf/go/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:54724/fyf/go/collection1
at 
__randomizedtesting.SeedInfo.seed([5C1546B02CFBAB9E:D441796A8207C666]: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:551)
at 
org.apache.solr.TestDistributedMissingSort.index(TestDistributedMissingSort.java:48)
at 
org.apache.solr.TestDistributedMissingSort.test(TestDistributedMissingSort.java:42)
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 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1022)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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

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

2016-02-27 Thread Policeman Jenkins Server

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

1 tests failed.
FAILED:  org.apache.lucene.search.TestTermAutomatonQuery.testRandom

Error Message:
expected:<211> but was:<343>

Stack Trace:
java.lang.AssertionError: expected:<211> but was:<343>
at 
__randomizedtesting.SeedInfo.seed([71C0B5765FF6AA81:38C9079EE961CF2]: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.lucene.search.TestTermAutomatonQuery.testRandom(TestTermAutomatonQuery.java:604)
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 8849 lines...]
   [junit4] Suite: org.apache.lucene.search.TestTermAutomatonQuery
   [junit4]   1> FAILED:
   [junit4]   1>   id=351 matched but should not have
   [junit4]   1>   id=234 matched but should not have
   [junit4]   1>   id=357 matched but should not have
   [junit4]   1>   id=358 matched but should not have
   [junit4]   1>   id=237 matched but should not have
   [junit4]   1>   id=359 matched but should not have
   [junit4]   1>   id=238

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

2016-02-27 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16024/
Java: 32bit/jdk-9-ea+106 -client -XX:+UseG1GC

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=11636, 
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)2) Thread[id=11639, 
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=11640, 
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)4) Thread[id=11638, 
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=11637, 
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)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=11636, 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)
   2) Thread[id=11639, name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at

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

2016-02-27 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski commented on SOLR-8110:
---

bq. If we expand the set to include what people may have used in the past 
(dashes, dots, etc), that sort of takes us full circle back to the state of 
things today

That's not quite true. Even if we allow all the characters that've been brought 
up by this JIRA (dashes, dots, underscores), this JIRA would still treat many 
others as invalid: slashes, spaces, unicode characters, most of the number-row 
of your keyboard (!@#$%^&()+), etc.

I doubt there's a ton of people using dollar-signs in their field names, but 
anyone who does will probably see some quirky behavior.  And if we can warn up 
front about that, even for rarely used characters, that might still be valuable.

> 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
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> 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

[jira] [Created] (SOLR-8753) When a replica attempts to become leader and cannot, it should not update its last published state when it moves into RECOVERING.

2016-02-27 Thread Mark Miller (JIRA)

Mark Miller created SOLR-8753:
-

 Summary: When a replica attempts to become leader and cannot, it 
should not update its last published state when it moves into RECOVERING.
 Key: SOLR-8753
 URL: https://issues.apache.org/jira/browse/SOLR-8753
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Mark Miller


The reason it could not become leader may be temporary. Currently, whenever you 
give up trying to become leader, you also poison any future attempt by making 
the last published state not ACTIVE when getting back in line.



--
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-8725) Cores, collections, and shards should accept hyphens in identifier name

2016-02-27 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski commented on SOLR-8725:
---

Hey [~anshumg], were you planning on changing the messages that get returned 
from the core/collection/shard APIs when an invalid identifier is used?  I 
think they mention specifically what characters are allowed in a valid 
identifier.  If the regex is changing, the messages should probably be updated 
also.  (Might make sense to pull the message into a single constant that lives 
in {{SolrIdentifierValidator}} too, but maybe it doesn't, I'd have to look.)

Happy to update the patch myself with those changes if you want.  Wanted to 
check first though; didn't want to step on your toes if there's a reason you 
didn't do it.

> Cores, collections, and shards should accept hyphens in identifier name
> ---
>
> Key: SOLR-8725
> URL: https://issues.apache.org/jira/browse/SOLR-8725
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5
>Reporter: Chris Beer
>Assignee: Anshum Gupta
> Attachments: SOLR-8725.patch
>
>
> In SOLR-8642, hyphens are no longer considered valid identifiers for cores 
> (and collections?). Our solr instance was successfully using hyphens in our 
> core names, and our affected cores now error with:
> marc-profiler_shard1_replica1: 
> org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist 
> entirely of periods, underscores and alphanumerics
> Before starting to rename all of our collections, I wonder if this decision 
> could be revisited to be backwards compatible with previously created 
> collections.



--
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-8721) Add Solr version to debug response

2016-02-27 Thread Marius Grama (JIRA)


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

Marius Grama commented on SOLR-8721:


I've created a pull request for this ticket.

The extra debug output coming with this change looks like this : 

{code:json}
"debug": {
"solr-spec-version": "5.5.0",
"solr-impl-version": "5.5.0-SNAPSHOT 
4e1c381b32b7b7630db5f1e24a3a8ab62605ced1 - marius - 2016-02-27 16:11:33",
"lucene-spec-version": "5.5.0",
"lucene-impl-version": "5.5.0-SNAPSHOT 
c7214a2ba5f96492e5c4cd6a558734217afe5089 - marius - 2016-02-26 20:59:35",

}
{code}


> Add Solr version to debug response
> --
>
> Key: SOLR-8721
> URL: https://issues.apache.org/jira/browse/SOLR-8721
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
>
> In troubleshooting customer issues, often they'll send send a Solr debug=true 
> output.  It'd be helpful to have more information, such as the Solr version 
> number, in the response.



--
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-8721) Add Solr version to debug response

2016-02-27 Thread Marius Grama (JIRA)


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

Marius Grama edited comment on SOLR-8721 at 2/27/16 3:30 PM:
-

I've created a pull request for this ticket.

The extra debug output coming with this change looks like this : 

{code}
"debug": {
"solr-spec-version": "5.5.0",
"solr-impl-version": "5.5.0-SNAPSHOT 
4e1c381b32b7b7630db5f1e24a3a8ab62605ced1 - marius - 2016-02-27 16:11:33",
"lucene-spec-version": "5.5.0",
"lucene-impl-version": "5.5.0-SNAPSHOT 
c7214a2ba5f96492e5c4cd6a558734217afe5089 - marius - 2016-02-26 20:59:35",

}
{code}



was (Author: mariusneo):
I've created a pull request for this ticket.

The extra debug output coming with this change looks like this : 

{code:json}
"debug": {
"solr-spec-version": "5.5.0",
"solr-impl-version": "5.5.0-SNAPSHOT 
4e1c381b32b7b7630db5f1e24a3a8ab62605ced1 - marius - 2016-02-27 16:11:33",
"lucene-spec-version": "5.5.0",
"lucene-impl-version": "5.5.0-SNAPSHOT 
c7214a2ba5f96492e5c4cd6a558734217afe5089 - marius - 2016-02-26 20:59:35",

}
{code}


> Add Solr version to debug response
> --
>
> Key: SOLR-8721
> URL: https://issues.apache.org/jira/browse/SOLR-8721
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
>
> In troubleshooting customer issues, often they'll send send a Solr debug=true 
> output.  It'd be helpful to have more information, such as the Solr version 
> number, in the response.



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

[GitHub] lucene-solr pull request: SOLR-8721 Added solr & lucene version to...

2016-02-27 Thread mariusneo

Github user mariusneo commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/16#discussion_r54334700
  
--- Diff: 
solr/core/src/java/org/apache/solr/handler/component/DebugComponent.java ---
@@ -177,7 +176,7 @@ public void modifyRequest(ResponseBuilder rb, 
SearchComponent who, ShardRequest
 }
   }
 } else {
-  sreq.params.set(CommonParams.DEBUG_QUERY, "false");
+  sreq.params.set(CommonParams.DEBUG_QUERY, rb.isDebugAll() ? "true" : 
"false");
--- End diff --

This may look cumbersome, but it is needed in order to be able pass the 
"debugQuery" parameter to the shard in case that the query is distributed and 
doesn't return any results.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (SOLR-8721) Add Solr version to debug response

2016-02-27 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on SOLR-8721:
--

Github user mariusneo commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/16#discussion_r54334700
  
--- Diff: 
solr/core/src/java/org/apache/solr/handler/component/DebugComponent.java ---
@@ -177,7 +176,7 @@ public void modifyRequest(ResponseBuilder rb, 
SearchComponent who, ShardRequest
 }
   }
 } else {
-  sreq.params.set(CommonParams.DEBUG_QUERY, "false");
+  sreq.params.set(CommonParams.DEBUG_QUERY, rb.isDebugAll() ? "true" : 
"false");
--- End diff --

This may look cumbersome, but it is needed in order to be able pass the 
"debugQuery" parameter to the shard in case that the query is distributed and 
doesn't return any results.


> Add Solr version to debug response
> --
>
> Key: SOLR-8721
> URL: https://issues.apache.org/jira/browse/SOLR-8721
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
>
> In troubleshooting customer issues, often they'll send send a Solr debug=true 
> output.  It'd be helpful to have more information, such as the Solr version 
> number, in the response.



--
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-8721) Add Solr version to debug response

2016-02-27 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on SOLR-8721:
--

GitHub user mariusneo opened a pull request:

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

SOLR-8721 Added solr & lucene version to the response for debug reasons

Added solr & lucene version to the response of the query handlers for debug 
purpsoses.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mariusneo/lucene-solr feature/SOLR-8721

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/16.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #16


commit 3c4ca8b499c6df68d6c1b1d5fd1300565024ca4d
Author: Marius 
Date:   2016-02-27T15:23:24Z

SOLR-8721 Added solr & lucene version to the response of the query handlers 
for debug purpsoses.




> Add Solr version to debug response
> --
>
> Key: SOLR-8721
> URL: https://issues.apache.org/jira/browse/SOLR-8721
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
>
> In troubleshooting customer issues, often they'll send send a Solr debug=true 
> output.  It'd be helpful to have more information, such as the Solr version 
> number, in the response.



--
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] [Resolved] (LUCENE-7052) BytesRefHash.sort should always sort in unicode code point order

2016-02-27 Thread Michael McCandless (JIRA)


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

Michael McCandless resolved LUCENE-7052.

Resolution: Fixed

> BytesRefHash.sort should always sort in unicode code point order
> 
>
> Key: LUCENE-7052
> URL: https://issues.apache.org/jira/browse/LUCENE-7052
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master, 6.0
>
> Attachments: LUCENE-7052.patch
>
>
> Today {{BytesRefHash.sort}} takes a custom {{Comparator}} but we always pass 
> it {{BytesRef.getUTF8SortedAsUnicodeComparator()}}.



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

[GitHub] lucene-solr pull request: SOLR-8721 Added solr & lucene version to...

2016-02-27 Thread mariusneo

GitHub user mariusneo opened a pull request:

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

SOLR-8721 Added solr & lucene version to the response for debug reasons

Added solr & lucene version to the response of the query handlers for debug 
purpsoses.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mariusneo/lucene-solr feature/SOLR-8721

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/16.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #16


commit 3c4ca8b499c6df68d6c1b1d5fd1300565024ca4d
Author: Marius 
Date:   2016-02-27T15:23:24Z

SOLR-8721 Added solr & lucene version to the response of the query handlers 
for debug purpsoses.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (LUCENE-7052) BytesRefHash.sort should always sort in unicode code point order

2016-02-27 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-7052:


Yeah, just shrinking the API.

> BytesRefHash.sort should always sort in unicode code point order
> 
>
> Key: LUCENE-7052
> URL: https://issues.apache.org/jira/browse/LUCENE-7052
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master, 6.0
>
> Attachments: LUCENE-7052.patch
>
>
> Today {{BytesRefHash.sort}} takes a custom {{Comparator}} but we always pass 
> it {{BytesRef.getUTF8SortedAsUnicodeComparator()}}.



--
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: lucene-solr git commit: SOLR-8697: Add synchronization around registering as leader and canceling.

2016-02-27 Thread Mark Miller

Thanks Shalin!

- Mark

On Sat, Feb 27, 2016 at 2:08 AM Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> I pushed a fix.
>
> On Sat, Feb 27, 2016 at 9:25 AM, Scott Blum  wrote:
> > That's annoying, since there's no semantic difference between that and a
> > log.warn(fmt, arg, arg).  Except that this particular logging API doesn't
> > have an overload that takes a throwable, a format string, and a set of
> args.
> >
> > On Fri, Feb 26, 2016 at 8:02 PM, Chris Hostetter <
> hossman_luc...@fucit.org>
> > wrote:
> >>
> >>
> >> this breaks precommit...
> >>
> >>
> >> [forbidden-apis] Forbidden method invocation:
> >> java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses
> default
> >> locale]
> >> [forbidden-apis]   in
> org.apache.solr.cloud.OverseerTest$MockZKController
> >> (OverseerTest.java:128)
> >> [forbidden-apis] Scanned 3181 (and 1946 related) class file(s) for
> >> forbidden API invocations (in 1.27s), 1 error(s).
> >>
> >>
> >>
> >>
> >> : Date: Fri, 26 Feb 2016 17:32:25 + (UTC)
> >> : From: markrmil...@apache.org
> >> : Reply-To: dev@lucene.apache.org
> >> : To: comm...@lucene.apache.org
> >> : Subject: lucene-solr git commit: SOLR-8697: Add synchronization around
> >> : registering as leader and canceling.
> >> :
> >> : Repository: lucene-solr
> >> : Updated Branches:
> >> :   refs/heads/master 0ed625b10 -> efb7bb171
> >> :
> >> :
> >> : SOLR-8697: Add synchronization around registering as leader and
> >> canceling.
> >> :
> >> :
> >> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> >> : Commit:
> >> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/efb7bb17
> >> : Tree:
> http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/efb7bb17
> >> : Diff:
> http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/efb7bb17
> >> :
> >> : Branch: refs/heads/master
> >> : Commit: efb7bb171b22a3c6a00d30eefe935a0024df0c71
> >> : Parents: 0ed625b
> >> : Author: markrmiller 
> >> : Authored: Fri Feb 26 12:32:12 2016 -0500
> >> : Committer: markrmiller 
> >> : Committed: Fri Feb 26 12:32:12 2016 -0500
> >> :
> >> : --
> >> :  .../org/apache/solr/cloud/ElectionContext.java  | 110
> >> ++-
> >> :  .../org/apache/solr/cloud/ZkController.java |   2 +-
> >> :  .../org/apache/solr/cloud/OverseerTest.java |   7 ++
> >> :  3 files changed, 69 insertions(+), 50 deletions(-)
> >> : --
> >> :
> >> :
> >> :
> >>
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/efb7bb17/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
> >> : --
> >> : diff --git
> >> a/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
> >> b/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
> >> : index da4b0c6..6743436 100644
> >> : --- a/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
> >> : +++ b/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
> >> : @@ -110,8 +110,11 @@ class ShardLeaderElectionContextBase extends
> >> ElectionContext {
> >> :protected String shardId;
> >> :protected String collection;
> >> :protected LeaderElector leaderElector;
> >> : -  protected volatile Integer leaderZkNodeParentVersion;
> >> : -
> >> : +  private Integer leaderZkNodeParentVersion;
> >> : +
> >> : +  // Prevents a race between cancelling and becoming leader.
> >> : +  private final Object lock = new Object();
> >> : +
> >> :public ShardLeaderElectionContextBase(LeaderElector leaderElector,
> >> :final String shardId, final String collection, final String
> >> coreNodeName,
> >> :ZkNodeProps props, ZkStateReader zkStateReader) {
> >> : @@ -138,31 +141,33 @@ class ShardLeaderElectionContextBase extends
> >> ElectionContext {
> >> :@Override
> >> :public void cancelElection() throws InterruptedException,
> >> KeeperException {
> >> :  super.cancelElection();
> >> : -if (leaderZkNodeParentVersion != null) {
> >> : -  try {
> >> : -// We need to be careful and make sure we *only* delete our
> own
> >> leader registration node.
> >> : -// We do this by using a multi and ensuring the parent znode
> of
> >> the leader registration node
> >> : -// matches the version we expect - there is a setData call
> that
> >> increments the parent's znode
> >> : -// version whenever a leader registers.
> >> : -log.info("Removing leader registration node on cancel: {}
> {}",
> >> leaderPath, leaderZkNodeParentVersion);
> >> : -List ops = new ArrayList<>(2);
> >> : -ops.add(Op.check(new Path(leaderPath).getParent().toString(),
> >> leaderZkNodeParentVersion));
> >> : -ops.add(Op.delete(leaderPath, -1));
> >> : -zkClient.multi(ops, true);
> >> :

[jira] [Commented] (LUCENE-7052) BytesRefHash.sort should always sort in unicode code point order

2016-02-27 Thread Adrien Grand (JIRA)


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

Adrien Grand commented on LUCENE-7052:
--

+1 for the simplification

> BytesRefHash.sort should always sort in unicode code point order
> 
>
> Key: LUCENE-7052
> URL: https://issues.apache.org/jira/browse/LUCENE-7052
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master, 6.0
>
> Attachments: LUCENE-7052.patch
>
>
> Today {{BytesRefHash.sort}} takes a custom {{Comparator}} but we always pass 
> it {{BytesRef.getUTF8SortedAsUnicodeComparator()}}.



--
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 # 16023 - Failure!

2016-02-27 Thread Policeman Jenkins Server

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

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:43103//collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:43103//collection1
at 
__randomizedtesting.SeedInfo.seed([24AC678CCDFBFDFB:ACF8585663079003]: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:551)
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:1022)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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)

[jira] [Commented] (SOLR-8752) Add a test for SizeLimitedDistributedMap

2016-02-27 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-8752: Add change log entry


> Add a test for SizeLimitedDistributedMap
> 
>
> Key: SOLR-8752
> URL: https://issues.apache.org/jira/browse/SOLR-8752
> Project: Solr
>  Issue Type: Test
>  Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master, 6.0
>
> Attachments: SOLR-8752.patch
>
>
> This class performs cleanup logic on a put operation. We should add a test 
> for it and beef up javadocs.



--
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-6453) Specialize SpanPositionQueue similar to DisiPriorityQueue

2016-02-27 Thread Paul Elschot (JIRA)


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

Paul Elschot commented on LUCENE-6453:
--

It would probably be best to support this with a performance benchmark, but I 
don't have the time to do that now.

> Specialize SpanPositionQueue similar to DisiPriorityQueue
> -
>
> Key: LUCENE-6453
> URL: https://issues.apache.org/jira/browse/LUCENE-6453
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Paul Elschot
>Priority: Minor
> Fix For: master, 6.0
>
> Attachments: LUCENE-6453.patch, LUCENE-6453.patch, LUCENE-6453.patch, 
> LUCENE-6453.patch
>
>
> Inline the position comparison function



--
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-7052) BytesRefHash.sort should always sort in unicode code point order

2016-02-27 Thread Dawid Weiss (JIRA)


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

Dawid Weiss commented on LUCENE-7052:
-

Are you for simplifying the code? Because I doubt it'll be any speed 
improvement.

> BytesRefHash.sort should always sort in unicode code point order
> 
>
> Key: LUCENE-7052
> URL: https://issues.apache.org/jira/browse/LUCENE-7052
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master, 6.0
>
> Attachments: LUCENE-7052.patch
>
>
> Today {{BytesRefHash.sort}} takes a custom {{Comparator}} but we always pass 
> it {{BytesRef.getUTF8SortedAsUnicodeComparator()}}.



--
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 # 881 - Still Failing

2016-02-27 Thread Apache Jenkins Server

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

1 tests failed.
FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'first' for path 
'response/params/x/_appends_/add' full output: {   "responseHeader":{ 
"status":0, "QTime":0},   "response":{ "znodeVersion":3, "params":{ 
  "x":{ "a":"A val", "b":"B val", "":{"v":0}},  
 "y":{ "p":"P val", "q":"Q val", "":{"v":2}

Stack Trace:
java.lang.AssertionError: Could not get expected value  'first' for path 
'response/params/x/_appends_/add' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":3,
"params":{
  "x":{
"a":"A val",
"b":"B val",
"":{"v":0}},
  "y":{
"p":"P val",
"q":"Q val",
"":{"v":2}
at 
__randomizedtesting.SeedInfo.seed([929D8D4CE220E931:1AC9B2964CDC84C9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:458)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:236)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:67)
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 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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

[jira] [Commented] (LUCENE-7052) BytesRefHash.sort should always sort in unicode code point order

2016-02-27 Thread Robert Muir (JIRA)


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

Robert Muir commented on LUCENE-7052:
-

+1

> BytesRefHash.sort should always sort in unicode code point order
> 
>
> Key: LUCENE-7052
> URL: https://issues.apache.org/jira/browse/LUCENE-7052
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master, 6.0
>
> Attachments: LUCENE-7052.patch
>
>
> Today {{BytesRefHash.sort}} takes a custom {{Comparator}} but we always pass 
> it {{BytesRef.getUTF8SortedAsUnicodeComparator()}}.



--
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] [Resolved] (SOLR-8712) Variable solr.core.instanceDir no longer resolved

2016-02-27 Thread Alan Woodward (JIRA)


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

Alan Woodward resolved SOLR-8712.
-
   Resolution: Fixed
Fix Version/s: 5.5.1
   master

Fixed - thanks for raising the issue Kristine!

> Variable solr.core.instanceDir no longer resolved
> -
>
> Key: SOLR-8712
> URL: https://issues.apache.org/jira/browse/SOLR-8712
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5
>Reporter: Kristine Jetzke
>Assignee: Alan Woodward
> Fix For: master, 5.5.1
>
> Attachments: SOLR-8712.patch
>
>
> In 5.4.1 standalone mode it was possible to use 
> {{$\{solr.core.instanceDir\}}} in the data import config file. This property 
> is no longer available in 5.5.0. 



--
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-8712) Variable solr.core.instanceDir no longer resolved

2016-02-27 Thread ASF subversion and git services (JIRA)


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

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

Commit 4e1c381b32b7b7630db5f1e24a3a8ab62605ced1 in lucene-solr's branch 
refs/heads/branch_5_5 from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4e1c381 ]

SOLR-8712: Variable solr.core.instanceDir was not being resolved


> Variable solr.core.instanceDir no longer resolved
> -
>
> Key: SOLR-8712
> URL: https://issues.apache.org/jira/browse/SOLR-8712
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5
>Reporter: Kristine Jetzke
>Assignee: Alan Woodward
> Attachments: SOLR-8712.patch
>
>
> In 5.4.1 standalone mode it was possible to use 
> {{$\{solr.core.instanceDir\}}} in the data import config file. This property 
> is no longer available in 5.5.0. 



--
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-7052) BytesRefHash.sort should always sort in unicode code point order

2016-02-27 Thread Michael McCandless (JIRA)


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

Michael McCandless updated LUCENE-7052:
---
Attachment: LUCENE-7052.patch

Simple patch.

> BytesRefHash.sort should always sort in unicode code point order
> 
>
> Key: LUCENE-7052
> URL: https://issues.apache.org/jira/browse/LUCENE-7052
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master, 6.0
>
> Attachments: LUCENE-7052.patch
>
>
> Today {{BytesRefHash.sort}} takes a custom {{Comparator}} but we always pass 
> it {{BytesRef.getUTF8SortedAsUnicodeComparator()}}.



--
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-7052) BytesRefHash.sort should always sort in unicode code point order

2016-02-27 Thread Michael McCandless (JIRA)

Michael McCandless created LUCENE-7052:
--

 Summary: BytesRefHash.sort should always sort in unicode code 
point order
 Key: LUCENE-7052
 URL: https://issues.apache.org/jira/browse/LUCENE-7052
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: master, 6.0


Today {{BytesRefHash.sort}} takes a custom {{Comparator}} but we always pass it 
{{BytesRef.getUTF8SortedAsUnicodeComparator()}}.



--
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-trunk - Build # 945 - Still Failing

2016-02-27 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/945/

3 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsUnloadDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=93198, 
name=testExecutor-12557-thread-1, state=RUNNABLE, 
group=TGRP-HdfsUnloadDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=93198, name=testExecutor-12557-thread-1, 
state=RUNNABLE, group=TGRP-HdfsUnloadDistributedZkTest]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:43148
at __randomizedtesting.SeedInfo.seed([FF9227C54CEE6865]:0)
at 
org.apache.solr.cloud.BasicDistributedZkTest$1.run(BasicDistributedZkTest.java:586)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:231)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.solr.client.solrj.SolrServerException: Timeout occured 
while waiting response from server at: http://127.0.0.1:43148
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:588)
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.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.BasicDistributedZkTest$1.run(BasicDistributedZkTest.java:584)
... 4 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
at 
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at 
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
at 
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:685)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:487)
at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:482)
... 8 more


FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
timed out waiting for collection1 startAt time to exceed: Sat Feb 27 01:16:58 
PST 2016

Stack Trace:
java.lang.AssertionError: timed out waiting for collection1 startAt time to 
exceed: Sat Feb 27 01:16:58 PST 2016
at 
__randomizedtesting.SeedInfo.seed([FF9227C54CEE6865:2439270349C601D6]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.handler.TestReplicationHandler.watchCoreStartAt(TestReplicationHandler.java:1419)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:771)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at

[JENKINS] Lucene-Solr-5.5-Solaris (multiarch/jdk1.7.0) - Build # 16 - Failure!

2016-02-27 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Solaris/16/
Java: multiarch/jdk1.7.0 -d64 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.StressHdfsTest.test

Error Message:
Error from server at http://127.0.0.1:44574/bo: Could not fully create 
collection: delete_data_dir

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:44574/bo: Could not fully create collection: 
delete_data_dir
at 
__randomizedtesting.SeedInfo.seed([1AD1ADCA981493F:89F92506077D24C7]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:576)
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.BasicDistributedZkTest.createCollection(BasicDistributedZkTest.java:665)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1523)
at 
org.apache.solr.cloud.hdfs.StressHdfsTest.createAndDeleteCollection(StressHdfsTest.java:153)
at 
org.apache.solr.cloud.hdfs.StressHdfsTest.test(StressHdfsTest.java:99)
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

[jira] [Commented] (SOLR-8712) Variable solr.core.instanceDir no longer resolved

2016-02-27 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-8712: Variable solr.core.instanceDir was not being resolved


> Variable solr.core.instanceDir no longer resolved
> -
>
> Key: SOLR-8712
> URL: https://issues.apache.org/jira/browse/SOLR-8712
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5
>Reporter: Kristine Jetzke
>Assignee: Alan Woodward
> Attachments: SOLR-8712.patch
>
>
> In 5.4.1 standalone mode it was possible to use 
> {{$\{solr.core.instanceDir\}}} in the data import config file. This property 
> is no longer available in 5.5.0. 



--
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-Solaris (64bit/jdk1.8.0) - Build # 432 - Still Failing!

2016-02-27 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/432/
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([7210C9288A676696:FA44F6F2249B0B6E]: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:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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

[jira] [Commented] (SOLR-8746) Document the usage and difference between various overseer queues, rename methods if necessary

2016-02-27 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar commented on SOLR-8746:
-

Thanks [~dragonsinth] for prodding me to add these docs!

> Document the usage and difference between various overseer queues, rename 
> methods if necessary
> --
>
> Key: SOLR-8746
> URL: https://issues.apache.org/jira/browse/SOLR-8746
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master, 6.0
>
> Attachments: SOLR-8746.patch
>
>
> The various overseer queues can use better javadocs to document their purpose 
> and usage. The method names such as getInQueue, getInternalQueue and 
> getCollectionQueue aren't descriptive enough.



--
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] [Resolved] (SOLR-8748) OverseerTaskProcessor limits number of concurrent tasks to just 10 even though the thread pool size is 100

2016-02-27 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar resolved SOLR-8748.
-
Resolution: Fixed
  Assignee: Shalin Shekhar Mangar

> OverseerTaskProcessor limits number of concurrent tasks to just 10 even 
> though the thread pool size is 100
> --
>
> Key: SOLR-8748
> URL: https://issues.apache.org/jira/browse/SOLR-8748
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.10.4, 5.5
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master, 6.0
>
> Attachments: SOLR-8748.patch
>
>
> OverseerTaskProcessor uses maxParallelThreads to limit number of concurrent 
> tasks but the same is not used for creating the thread pool. The default 
> limit of 10 is too small, IMO and we should change it to 100. The overseer 
> collection processor mostly just waits around on network calls so there is no 
> harm in increasing this limit.



--
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-8746) Document the usage and difference between various overseer queues, rename methods if necessary

2016-02-27 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-8746: Renamed Overseer.getInQueue to getStateUpdateQueue, getInternalQueue 
to getInternalWorkQueue and added javadocs


> Document the usage and difference between various overseer queues, rename 
> methods if necessary
> --
>
> Key: SOLR-8746
> URL: https://issues.apache.org/jira/browse/SOLR-8746
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master, 6.0
>
> Attachments: SOLR-8746.patch
>
>
> The various overseer queues can use better javadocs to document their purpose 
> and usage. The method names such as getInQueue, getInternalQueue and 
> getCollectionQueue aren't descriptive enough.



--
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-8748) OverseerTaskProcessor limits number of concurrent tasks to just 10 even though the thread pool size is 100

2016-02-27 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar commented on SOLR-8748:
-

Shout out to [~dragonsinth] for finding this bug.

> OverseerTaskProcessor limits number of concurrent tasks to just 10 even 
> though the thread pool size is 100
> --
>
> Key: SOLR-8748
> URL: https://issues.apache.org/jira/browse/SOLR-8748
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.10.4, 5.5
>Reporter: Shalin Shekhar Mangar
> Fix For: master, 6.0
>
> Attachments: SOLR-8748.patch
>
>
> OverseerTaskProcessor uses maxParallelThreads to limit number of concurrent 
> tasks but the same is not used for creating the thread pool. The default 
> limit of 10 is too small, IMO and we should change it to 100. The overseer 
> collection processor mostly just waits around on network calls so there is no 
> harm in increasing this limit.



--
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-8748) OverseerTaskProcessor limits number of concurrent tasks to just 10 even though the thread pool size is 100

2016-02-27 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-8748: OverseerTaskProcessor limits number of concurrent tasks to just 10 
even though the thread pool size is 100. The limit has now been increased to 
100.


> OverseerTaskProcessor limits number of concurrent tasks to just 10 even 
> though the thread pool size is 100
> --
>
> Key: SOLR-8748
> URL: https://issues.apache.org/jira/browse/SOLR-8748
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.10.4, 5.5
>Reporter: Shalin Shekhar Mangar
> Fix For: master, 6.0
>
> Attachments: SOLR-8748.patch
>
>
> OverseerTaskProcessor uses maxParallelThreads to limit number of concurrent 
> tasks but the same is not used for creating the thread pool. The default 
> limit of 10 is too small, IMO and we should change it to 100. The overseer 
> collection processor mostly just waits around on network calls so there is no 
> harm in increasing this limit.



--
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] [Resolved] (SOLR-8220) Read field from docValues for non stored fields

2016-02-27 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar resolved SOLR-8220.
-
   Resolution: Fixed
Fix Version/s: 5.5
   6.0

This was released in 5.5 so I am resolving this.

[~dsmiley] -- please open new issues if you want to change this feature for 6.0 
in any way.

> Read field from docValues for non stored fields
> ---
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
>Assignee: Shalin Shekhar Mangar
> Fix For: 6.0, 5.5
>
> Attachments: SOLR-8220-5x.patch, SOLR-8220-branch_5x.patch, 
> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, 
> SOLR-8220-ishan.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>-- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



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

82 matches

Mail list logo