[jira] [Updated] (LUCENE-6453) Specialize SpanPositionQueue similar to DisiPriorityQueue

[Paul Elschot (JIRA)]

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

Paul Elschot updated LUCENE-6453:
-
Attachment: LUCENE-6453.patch

Patch of 9 Jan 2016.

Updated to trunk.

This uses SpansT as a type name, following this style guide:

https://google.github.io/styleguide/javaguide.html#s5.2.8-type-variable-names

> 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: 5.5, Trunk
>
> 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

[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_66) - Build # 5405 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5405/
Java: 32bit/jdk1.8.0_66 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testMaxDocs

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([7CBD14C4C82E5F1D:C53CC21BE4C45B97]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:753)
at 
org.apache.solr.update.AutoCommitTest.testMaxDocs(AutoCommitTest.java:199)
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:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:14=standard=0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:746)
... 40 more




Build Log:
[...truncated 9821 lines...]
   [junit4] Suite: org.apache.solr.update.AutoCommitTest
   [junit4]   2> 

[jira] [Commented] (SOLR-8525) Dimensional info not passed on to FieldInfos

[Michael McCandless (JIRA)]

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

Michael McCandless commented on SOLR-8525:
--

Thanks [~ichattopadhyaya], this looks good!  I'll commit shortly...

> Dimensional info not passed on to FieldInfos
> 
>
> Key: SOLR-8525
> URL: https://issues.apache.org/jira/browse/SOLR-8525
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: SOLR-8525.patch
>
>
> Similar to LUCENE-6950, there are some places in Solr where dimensional 
> values are not passed along when creating a new FieldInfo object from an 
> older one.



--
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-6938) Convert build to work with Git rather than SVN.

[Upayavira (JIRA)]

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

Upayavira commented on LUCENE-6938:
---

How about the main build gets the git hash and writes it to a temporary 
property file. All other build phases can then just read that file and we are 
done. Am I missing something?

> Convert build to work with Git rather than SVN.
> ---
>
> Key: LUCENE-6938
> URL: https://issues.apache.org/jira/browse/LUCENE-6938
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: LUCENE-6938.patch
>
>
> We assume an SVN checkout in parts of our build and will need to move to 
> assuming a Git checkout.
> Patches against https://github.com/dweiss/lucene-solr-svn2git from 
> LUCENE-6933.



--
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.x-Linux (32bit/jdk1.7.0_80) - Build # 15196 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15196/
Java: 32bit/jdk1.7.0_80 -client -XX:+UseParallelGC

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

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

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:45828/awholynewcollection_0: non ok status: 
500, message:Server Error
at 
__randomizedtesting.SeedInfo.seed([F970D959E8FD202D:7124E68346014DD5]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:508)
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:150)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForNon403or404or503(AbstractFullDistribZkTestBase.java:1754)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:658)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:160)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Resolved] (SOLR-8525) Dimensional info not passed on to FieldInfos

[Michael McCandless (JIRA)]

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

Michael McCandless resolved SOLR-8525.
--
   Resolution: Fixed
Fix Version/s: Trunk

> Dimensional info not passed on to FieldInfos
> 
>
> Key: SOLR-8525
> URL: https://issues.apache.org/jira/browse/SOLR-8525
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-8525.patch
>
>
> Similar to LUCENE-6950, there are some places in Solr where dimensional 
> values are not passed along when creating a new FieldInfo object from an 
> older one.



--
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-6596) Make width of unordered near spans consistent with ordered

[Paul Elschot (JIRA)]

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

Paul Elschot updated LUCENE-6596:
-
Attachment: LUCENE-6596.patch

Patch of 9 Jan 2016.

Updated to trunk.

> Make width of unordered near spans consistent with ordered
> --
>
> Key: LUCENE-6596
> URL: https://issues.apache.org/jira/browse/LUCENE-6596
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: Trunk
>Reporter: Paul Elschot
>Priority: Minor
> Fix For: Trunk
>
> Attachments: LUCENE-6596.patch, LUCENE-6596.patch
>
>
> Use actual slop for width in NearSpansUnordered.



--
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-6938) Convert build to work with Git rather than SVN.

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6938:
---

bq. How about the main build gets the git hash and writes it to a temporary 
property file. All other build phases can then just read that file and we are 
done. Am I missing something?

Thats not good, because on git update it would not update that file unless you 
do ant clean. The solution proposed before is easy, I will implement it later, 
no worries. We have the infrastructure:
- a task will be added to common-build.xml that gets git hash and saves it in 
property. This task has {{unless="property"}}
- property is added to the patternset of properties to pass down the sub-modules
- all submodules JAR tasks call the task as dependency. But if the upper builds 
has already defined the property it is a no-op

No worries, I will take care! For now just use the approach we had with 
Subversion.

> Convert build to work with Git rather than SVN.
> ---
>
> Key: LUCENE-6938
> URL: https://issues.apache.org/jira/browse/LUCENE-6938
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: LUCENE-6938.patch
>
>
> We assume an SVN checkout in parts of our build and will need to move to 
> assuming a Git checkout.
> Patches against https://github.com/dweiss/lucene-solr-svn2git from 
> LUCENE-6933.



--
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-8525) Dimensional info not passed on to FieldInfos

[ASF subversion and git services (JIRA)]

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

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

Commit 1723845 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1723845 ]

SOLR-8525: fix a few places that were failing to pass dimensional values 
settings when copying a FieldInfo

> Dimensional info not passed on to FieldInfos
> 
>
> Key: SOLR-8525
> URL: https://issues.apache.org/jira/browse/SOLR-8525
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: SOLR-8525.patch
>
>
> Similar to LUCENE-6950, there are some places in Solr where dimensional 
> values are not passed along when creating a new FieldInfo object from an 
> older one.



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

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

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

[Apache Jenkins Server]

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

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

Error Message:
Captured an uncaught exception in thread: Thread[id=12228, name=collection3, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=12228, name=collection3, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
at 
__randomizedtesting.SeedInfo.seed([F8D786BCDB755BB6:7083B9667589364E]:0)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:52410/js_aay/yg: Could not find collection : 
awholynewstresscollection_collection3_0
at __randomizedtesting.SeedInfo.seed([F8D786BCDB755BB6]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575)
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.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:888)




Build Log:
[...truncated 11043 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/solr/build/solr-core/test/J0/temp/solr.cloud.CollectionsAPIDistributedZkTest_F8D786BCDB755BB6-001/init-core-data-001
   [junit4]   2> 1500555 INFO  
(SUITE-CollectionsAPIDistributedZkTest-seed#[F8D786BCDB755BB6]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false)
   [junit4]   2> 1500555 INFO  
(SUITE-CollectionsAPIDistributedZkTest-seed#[F8D786BCDB755BB6]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: 
/js_aay/yg
   [junit4]   2> 1500560 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[F8D786BCDB755BB6]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1500560 INFO  (Thread-6877) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1500560 INFO  (Thread-6877) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1500660 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[F8D786BCDB755BB6]) [] 
o.a.s.c.ZkTestServer start zk server on port:50082
   [junit4]   2> 1500661 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[F8D786BCDB755BB6]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1500664 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[F8D786BCDB755BB6]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1500673 INFO  (zkCallback-978-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@23e4e606 
name:ZooKeeperConnection Watcher:127.0.0.1:50082 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 1500674 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[F8D786BCDB755BB6]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 1500674 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[F8D786BCDB755BB6]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 1500674 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[F8D786BCDB755BB6]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 1500717 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[F8D786BCDB755BB6]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1500723 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[F8D786BCDB755BB6]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1500725 INFO  (zkCallback-979-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@79b87229 
name:ZooKeeperConnection Watcher:127.0.0.1:50082/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 1500725 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[F8D786BCDB755BB6]) [] 

[jira] [Commented] (LUCENE-6938) Convert build to work with Git rather than SVN.

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6938:
---

I will open serparate issue once we moved to Git and fix that, together with 
the check-svn-working-copy-task!

So lets do the move now!

> Convert build to work with Git rather than SVN.
> ---
>
> Key: LUCENE-6938
> URL: https://issues.apache.org/jira/browse/LUCENE-6938
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: LUCENE-6938.patch
>
>
> We assume an SVN checkout in parts of our build and will need to move to 
> assuming a Git checkout.
> Patches against https://github.com/dweiss/lucene-solr-svn2git from 
> LUCENE-6933.



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15200/
Java: 64bit/jdk-9-ea+95 -XX:-UseCompressedOops -XX:+UseParallelGC 
-XX:-CompactStrings

2 tests failed.
FAILED:  org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test

Error Message:
Doc with id=4 not found in http://127.0.0.1:43857/_nmy/c8n_1x3_lf due to: Path 
not found: /id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=4 not found in 
http://127.0.0.1:43857/_nmy/c8n_1x3_lf due to: Path not found: /id; 
rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([E95D58C1DD15BB74:6109671B73E9D68C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:620)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:575)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:103)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:56)
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.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 

[JENKINS] Lucene-Solr-SmokeRelease-5.3 - Build # 11 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.3/11/

No tests ran.

Build Log:
[...truncated 53068 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (10.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.3.2-src.tgz...
   [smoker] 28.5 MB in 0.04 sec (671.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.3.2.tgz...
   [smoker] 65.7 MB in 0.11 sec (624.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.3.2.zip...
   [smoker] 75.9 MB in 0.12 sec (652.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.3.2.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6059 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6059 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.3.2.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6059 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6059 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.3.2-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker]   5.4.0
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/dev-tools/scripts/smokeTestRelease.py",
 line 1449, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/dev-tools/scripts/smokeTestRelease.py",
 line 1394, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/dev-tools/scripts/smokeTestRelease.py",
 line 1432, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, svnRevision, version, testArgs, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/dev-tools/scripts/smokeTestRelease.py",
 line 583, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
svnRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/dev-tools/scripts/smokeTestRelease.py",
 line 762, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/dev-tools/scripts/smokeTestRelease.py",
 line 1387, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 

[jira] [Assigned] (LUCENE-6955) The release smoke tester inappropriately requires back compat index testing for versions greater than the one being smoke tested

[Steve Rowe (JIRA)]

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

Steve Rowe reassigned LUCENE-6955:
--

Assignee: Steve Rowe

> The release smoke tester inappropriately requires back compat index testing 
> for versions greater than the one being smoke tested
> 
>
> Key: LUCENE-6955
> URL: https://issues.apache.org/jira/browse/LUCENE-6955
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Affects Versions: 5.3.2
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 5.3.2
>
>
> I ran {{ant nightly-smoke}} on my laptop against the lucene_solr_5_3 branch 
> and got the following error:
> {noformat}
>[smoker] Verify...
>[smoker]   confirm all releases have coverage in TestBackwardsCompatibility
>[smoker] find all past Lucene releases...
>[smoker] run TestBackwardsCompatibility..
>[smoker] Releases that don't seem to be tested:
>[smoker]   5.4.0
>[smoker] Traceback (most recent call last):
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRele
>[smoker] ase.py", line 1449, in 
>[smoker] main()
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 1394, in main
>[smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
> c.is_signed, ' '.join(c.test_args))
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 1432, in smokeTest
>[smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
> version, svnRevision, version, testArgs, baseURL)
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 583, in unpackAndVerify
>[smoker] verifyUnpacked(java, project, artifact, unpackPath, 
> svnRevision, version, testArgs, tmpDir, baseURL)
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 762, in verifyUnpacked
>[smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 1387, in confirmAllReleasesAreTestedForBackCompat
>[smoker] raise RuntimeError('some releases are not tested by 
> TestBackwardsCompatibility?')
>[smoker] RuntimeError: some releases are not tested by 
> TestBackwardsCompatibility?
> {noformat}
> Here's the relevant section of {{smokeTestRelease.py}} - 
> {{getAllLuceneReleases()}} fetches all dotted-version entries in the file 
> listing page returned by the web server at 
> https://archive.apache.org/dist/lucene/java/:
> {code}
> def confirmAllReleasesAreTestedForBackCompat(unpackPath):
>   print('find all past Lucene releases...')
>   allReleases = getAllLuceneReleases()
>   [...]
>   notTested = []
>   for x in allReleases:
> if x not in testedIndices:
>   if '.'.join(str(y) for y in x) in ('1.4.3', '1.9.1', '2.3.1', '2.3.2'):
> # Exempt the dark ages indices
> continue
>   notTested.append(x)
>   if len(notTested) > 0:
> notTested.sort()
> print('Releases that don\'t seem to be tested:')
> failed = True
> for x in notTested:
>   print('  %s' % '.'.join(str(y) for y in x))
> raise RuntimeError('some releases are not tested by 
> TestBackwardsCompatibility?')
> {code}
> I think the code above should allow/ignore versions greater than the version 
> being smoke tested.
> AFAIK, version 5.3.2 will be the first release where a greater version has 
> been released in the past since full back compat testing started being 
> checked for by the smoke tester.  (The last time this happened was when 4.9.1 
> was released after 4.10.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-6955) The release smoke tester inappropriately requires back compat index testing for versions not less than the one being smoke tested

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-6955:
---
Attachment: LUCENE-6955.patch

Improved wording of notification for releases exempted from backcompat testing.

> The release smoke tester inappropriately requires back compat index testing 
> for versions not less than the one being smoke tested
> -
>
> Key: LUCENE-6955
> URL: https://issues.apache.org/jira/browse/LUCENE-6955
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Affects Versions: 5.3.2
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 5.3.2
>
> Attachments: LUCENE-6955.patch, LUCENE-6955.patch
>
>
> I ran {{ant nightly-smoke}} on my laptop against the lucene_solr_5_3 branch 
> and got the following error:
> {noformat}
>[smoker] Verify...
>[smoker]   confirm all releases have coverage in TestBackwardsCompatibility
>[smoker] find all past Lucene releases...
>[smoker] run TestBackwardsCompatibility..
>[smoker] Releases that don't seem to be tested:
>[smoker]   5.4.0
>[smoker] Traceback (most recent call last):
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRele
>[smoker] ase.py", line 1449, in 
>[smoker] main()
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 1394, in main
>[smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
> c.is_signed, ' '.join(c.test_args))
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 1432, in smokeTest
>[smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
> version, svnRevision, version, testArgs, baseURL)
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 583, in unpackAndVerify
>[smoker] verifyUnpacked(java, project, artifact, unpackPath, 
> svnRevision, version, testArgs, tmpDir, baseURL)
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 762, in verifyUnpacked
>[smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 1387, in confirmAllReleasesAreTestedForBackCompat
>[smoker] raise RuntimeError('some releases are not tested by 
> TestBackwardsCompatibility?')
>[smoker] RuntimeError: some releases are not tested by 
> TestBackwardsCompatibility?
> {noformat}
> Here's the relevant section of {{smokeTestRelease.py}} - 
> {{getAllLuceneReleases()}} fetches all dotted-version entries in the file 
> listing page returned by the web server at 
> https://archive.apache.org/dist/lucene/java/:
> {code}
> def confirmAllReleasesAreTestedForBackCompat(unpackPath):
>   print('find all past Lucene releases...')
>   allReleases = getAllLuceneReleases()
>   [...]
>   notTested = []
>   for x in allReleases:
> if x not in testedIndices:
>   if '.'.join(str(y) for y in x) in ('1.4.3', '1.9.1', '2.3.1', '2.3.2'):
> # Exempt the dark ages indices
> continue
>   notTested.append(x)
>   if len(notTested) > 0:
> notTested.sort()
> print('Releases that don\'t seem to be tested:')
> failed = True
> for x in notTested:
>   print('  %s' % '.'.join(str(y) for y in x))
> raise RuntimeError('some releases are not tested by 
> TestBackwardsCompatibility?')
> {code}
> I think the code above should allow/ignore versions greater than the version 
> being smoke tested.
> AFAIK, version 5.3.2 will be the first release where a greater version has 
> been released in the past since full back compat testing started being 
> checked for by the smoke tester.  (The last time this happened was when 4.9.1 
> was released after 4.10.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-6938) Convert build to work with Git rather than SVN.

[Mark Miller (JIRA)]

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

Mark Miller updated LUCENE-6938:

Attachment: LUCENE-6938.patch

> Convert build to work with Git rather than SVN.
> ---
>
> Key: LUCENE-6938
> URL: https://issues.apache.org/jira/browse/LUCENE-6938
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: LUCENE-6938.patch, LUCENE-6938.patch, LUCENE-6938.patch
>
>
> We assume an SVN checkout in parts of our build and will need to move to 
> assuming a Git checkout.
> Patches against https://github.com/dweiss/lucene-solr-svn2git from 
> LUCENE-6933.



--
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+95) - Build # 15497 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15497/
Java: 64bit/jdk-9-ea+95 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 
-XX:-CompactStrings

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

Error Message:
timed out waiting for collection1 startAt time to exceed: Sun Jan 10 07:10:34 
PGT 2016

Stack Trace:
java.lang.AssertionError: timed out waiting for collection1 startAt time to 
exceed: Sun Jan 10 07:10:34 PGT 2016
at 
__randomizedtesting.SeedInfo.seed([C2723828F8B1194B:19D938EEFD9970F8]: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 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:747)




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

[jira] [Updated] (LUCENE-6938) Convert build to work with Git rather than SVN.

[Mark Miller (JIRA)]

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

Mark Miller updated LUCENE-6938:

Attachment: LUCENE-6938.patch

> Convert build to work with Git rather than SVN.
> ---
>
> Key: LUCENE-6938
> URL: https://issues.apache.org/jira/browse/LUCENE-6938
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: LUCENE-6938.patch, LUCENE-6938.patch, LUCENE-6938.patch, 
> LUCENE-6938.patch
>
>
> We assume an SVN checkout in parts of our build and will need to move to 
> assuming a Git checkout.
> Patches against https://github.com/dweiss/lucene-solr-svn2git from 
> LUCENE-6933.



--
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-8531) ZK leader path changed in 5.4

[Jeff Wartes (JIRA)]

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

Jeff Wartes commented on SOLR-8531:
---

1. A fully upgraded cluster behaves normally.
2. The problem is only occurs for collections with replicationFactor > 1, but 
by definition, this means you only have problems if you're trying an HA upgrade.

Upgraded nodes got in line for leader election as normal, but could not figure 
out the current leader on start, and never executed replication recovery and 
became active. If I restarted 5.3 nodes for a given shard, the 5.4 shard would 
eventually get elected leader, and publish active state without intervention, 
but restarting the 5.4 shard again would mean a 5.3 shard got elected, and the 
5.4 node would be stuck in 'down' state again. I did not test restarting a 5.3 
shard while the 5.4 shard was leader.

In my case I had sufficient production capacity to upgrade half my cluster, 
create a new collection in 5.4, copy the data into it, and then upgrade the 
rest of the cluster, so I did that. 
As mentioned, taking downtime and upgrading the whole cluster at once would 
also have worked.


> ZK leader path changed in 5.4
> -
>
> Key: SOLR-8531
> URL: https://issues.apache.org/jira/browse/SOLR-8531
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4
>Reporter: Jeff Wartes
>
> While doing a rolling upgrade from 5.3 to 5.4 of a solrcloud cluster, I 
> observed that upgraded nodes would not register their shards as active unless 
> they were elected the leader for the shard.
> There were no errors, the shards were fully up and responsive, but would not  
> publish any change from the "down" state.
> This appears to be because the recovery process never happens, because the ZK 
> node containing the current leader can't be found, because the ZK path has 
> changed.
> Specifically, the leader data node changed from:
> /leaders/
> to
> /leaders//leader
> It looks to me like this happened during SOLR-7844, perhaps accidentally. 
> At the least, the "Migrating to Solr 5.4" section of the README should get 
> updated with this info, since it means a rolling upgrade of a collection with 
> multiple replicas will suffer serious degradation in the number of active 
> replicas as nodes are upgraded. It's entirely possible this will reduce some 
> shards to a single active replica.



--
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-6955) The release smoke tester inappropriately requires back compat index testing for versions not less than the one being smoke tested

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-6955:
---
Summary: The release smoke tester inappropriately requires back compat 
index testing for versions not less than the one being smoke tested  (was: The 
release smoke tester inappropriately requires back compat index testing for 
versions greater than the one being smoke tested)

> The release smoke tester inappropriately requires back compat index testing 
> for versions not less than the one being smoke tested
> -
>
> Key: LUCENE-6955
> URL: https://issues.apache.org/jira/browse/LUCENE-6955
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Affects Versions: 5.3.2
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 5.3.2
>
> Attachments: LUCENE-6955.patch
>
>
> I ran {{ant nightly-smoke}} on my laptop against the lucene_solr_5_3 branch 
> and got the following error:
> {noformat}
>[smoker] Verify...
>[smoker]   confirm all releases have coverage in TestBackwardsCompatibility
>[smoker] find all past Lucene releases...
>[smoker] run TestBackwardsCompatibility..
>[smoker] Releases that don't seem to be tested:
>[smoker]   5.4.0
>[smoker] Traceback (most recent call last):
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRele
>[smoker] ase.py", line 1449, in 
>[smoker] main()
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 1394, in main
>[smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
> c.is_signed, ' '.join(c.test_args))
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 1432, in smokeTest
>[smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
> version, svnRevision, version, testArgs, baseURL)
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 583, in unpackAndVerify
>[smoker] verifyUnpacked(java, project, artifact, unpackPath, 
> svnRevision, version, testArgs, tmpDir, baseURL)
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 762, in verifyUnpacked
>[smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 1387, in confirmAllReleasesAreTestedForBackCompat
>[smoker] raise RuntimeError('some releases are not tested by 
> TestBackwardsCompatibility?')
>[smoker] RuntimeError: some releases are not tested by 
> TestBackwardsCompatibility?
> {noformat}
> Here's the relevant section of {{smokeTestRelease.py}} - 
> {{getAllLuceneReleases()}} fetches all dotted-version entries in the file 
> listing page returned by the web server at 
> https://archive.apache.org/dist/lucene/java/:
> {code}
> def confirmAllReleasesAreTestedForBackCompat(unpackPath):
>   print('find all past Lucene releases...')
>   allReleases = getAllLuceneReleases()
>   [...]
>   notTested = []
>   for x in allReleases:
> if x not in testedIndices:
>   if '.'.join(str(y) for y in x) in ('1.4.3', '1.9.1', '2.3.1', '2.3.2'):
> # Exempt the dark ages indices
> continue
>   notTested.append(x)
>   if len(notTested) > 0:
> notTested.sort()
> print('Releases that don\'t seem to be tested:')
> failed = True
> for x in notTested:
>   print('  %s' % '.'.join(str(y) for y in x))
> raise RuntimeError('some releases are not tested by 
> TestBackwardsCompatibility?')
> {code}
> I think the code above should allow/ignore versions greater than the version 
> being smoke tested.
> AFAIK, version 5.3.2 will be the first release where a greater version has 
> been released in the past since full back compat testing started being 
> checked for by the smoke tester.  (The last time this happened was when 4.9.1 
> was released after 4.10.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] (LUCENE-6938) Convert build to work with Git rather than SVN.

[Mark Miller (JIRA)]

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

Mark Miller commented on LUCENE-6938:
-

https://github.com/markrmiller/lucene-solr-svn2git/commit/c587241d35f3dc641a2de26eff3ba2dc2f6eca59

> Convert build to work with Git rather than SVN.
> ---
>
> Key: LUCENE-6938
> URL: https://issues.apache.org/jira/browse/LUCENE-6938
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: LUCENE-6938.patch, LUCENE-6938.patch, LUCENE-6938.patch
>
>
> We assume an SVN checkout in parts of our build and will need to move to 
> assuming a Git checkout.
> Patches against https://github.com/dweiss/lucene-solr-svn2git from 
> LUCENE-6933.



--
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-8531) ZK leader path changed in 5.4

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8531:
---

Surface level, if I remember, I thought for backcompat on 5x, we continued 
writing the leader to both spots.

> ZK leader path changed in 5.4
> -
>
> Key: SOLR-8531
> URL: https://issues.apache.org/jira/browse/SOLR-8531
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4
>Reporter: Jeff Wartes
>
> While doing a rolling upgrade from 5.3 to 5.4 of a solrcloud cluster, I 
> observed that upgraded nodes would not register their shards as active unless 
> they were elected the leader for the shard.
> There were no errors, the shards were fully up and responsive, but would not  
> publish any change from the "down" state.
> This appears to be because the recovery process never happens, because the ZK 
> node containing the current leader can't be found, because the ZK path has 
> changed.
> Specifically, the leader data node changed from:
> /leaders/
> to
> /leaders//leader
> It looks to me like this happened during SOLR-7844, perhaps accidentally. 
> At the least, the "Migrating to Solr 5.4" section of the README should get 
> updated with this info, since it means a rolling upgrade of a collection with 
> multiple replicas will suffer serious degradation in the number of active 
> replicas as nodes are upgraded. It's entirely possible this will reduce some 
> shards to a single active replica.



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

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

[jira] [Assigned] (LUCENE-6937) Migrate Lucene project from SVN to Git.

[Mark Miller (JIRA)]

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

Mark Miller reassigned LUCENE-6937:
---

Assignee: Mark Miller

> Migrate Lucene project from SVN to Git.
> ---
>
> Key: LUCENE-6937
> URL: https://issues.apache.org/jira/browse/LUCENE-6937
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Assignee: Mark Miller
>
> See mailing list discussion: 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201512.mbox/%3CCAL8PwkbFVT83ZbCZm0y-x-MDeTH6HYC_xYEjRev9fzzk5YXYmQ%40mail.gmail.com%3E



--
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-6955) The release smoke tester inappropriately requires back compat index testing for versions greater than the one being smoke tested

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-6955:
---
Attachment: LUCENE-6955.patch

Testing this patch now.

Thinking through this a little more, in addition to versions greater than the 
one being smoke tested, we should also exempt the exact same version; {{ant 
nightly-smoke}} should not fail on a branch from an already released version.

> The release smoke tester inappropriately requires back compat index testing 
> for versions greater than the one being smoke tested
> 
>
> Key: LUCENE-6955
> URL: https://issues.apache.org/jira/browse/LUCENE-6955
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Affects Versions: 5.3.2
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 5.3.2
>
> Attachments: LUCENE-6955.patch
>
>
> I ran {{ant nightly-smoke}} on my laptop against the lucene_solr_5_3 branch 
> and got the following error:
> {noformat}
>[smoker] Verify...
>[smoker]   confirm all releases have coverage in TestBackwardsCompatibility
>[smoker] find all past Lucene releases...
>[smoker] run TestBackwardsCompatibility..
>[smoker] Releases that don't seem to be tested:
>[smoker]   5.4.0
>[smoker] Traceback (most recent call last):
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRele
>[smoker] ase.py", line 1449, in 
>[smoker] main()
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 1394, in main
>[smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
> c.is_signed, ' '.join(c.test_args))
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 1432, in smokeTest
>[smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
> version, svnRevision, version, testArgs, baseURL)
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 583, in unpackAndVerify
>[smoker] verifyUnpacked(java, project, artifact, unpackPath, 
> svnRevision, version, testArgs, tmpDir, baseURL)
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 762, in verifyUnpacked
>[smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
>[smoker]   File 
> "/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_3/dev-tools/scripts/smokeTestRelease.py",
>  line 1387, in confirmAllReleasesAreTestedForBackCompat
>[smoker] raise RuntimeError('some releases are not tested by 
> TestBackwardsCompatibility?')
>[smoker] RuntimeError: some releases are not tested by 
> TestBackwardsCompatibility?
> {noformat}
> Here's the relevant section of {{smokeTestRelease.py}} - 
> {{getAllLuceneReleases()}} fetches all dotted-version entries in the file 
> listing page returned by the web server at 
> https://archive.apache.org/dist/lucene/java/:
> {code}
> def confirmAllReleasesAreTestedForBackCompat(unpackPath):
>   print('find all past Lucene releases...')
>   allReleases = getAllLuceneReleases()
>   [...]
>   notTested = []
>   for x in allReleases:
> if x not in testedIndices:
>   if '.'.join(str(y) for y in x) in ('1.4.3', '1.9.1', '2.3.1', '2.3.2'):
> # Exempt the dark ages indices
> continue
>   notTested.append(x)
>   if len(notTested) > 0:
> notTested.sort()
> print('Releases that don\'t seem to be tested:')
> failed = True
> for x in notTested:
>   print('  %s' % '.'.join(str(y) for y in x))
> raise RuntimeError('some releases are not tested by 
> TestBackwardsCompatibility?')
> {code}
> I think the code above should allow/ignore versions greater than the version 
> being smoke tested.
> AFAIK, version 5.3.2 will be the first release where a greater version has 
> been released in the past since full back compat testing started being 
> checked for by the smoke tester.  (The last time this happened was when 4.9.1 
> was released after 4.10.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-6938) Convert build to work with Git rather than SVN.

[Mark Miller (JIRA)]

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

Mark Miller updated LUCENE-6938:

Attachment: LUCENE-6938.patch

Okay, here is what I think is the minimum patch that replicates what we had. 
Let's do that for this issue and open new issues for any improvements. That way 
we won't hold up the conversion at all and we can try and keep some momentum.

> Convert build to work with Git rather than SVN.
> ---
>
> Key: LUCENE-6938
> URL: https://issues.apache.org/jira/browse/LUCENE-6938
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: LUCENE-6938.patch, LUCENE-6938.patch
>
>
> We assume an SVN checkout in parts of our build and will need to move to 
> assuming a Git checkout.
> Patches against https://github.com/dweiss/lucene-solr-svn2git from 
> LUCENE-6933.



--
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.x-Windows (32bit/jdk1.8.0_66) - Build # 5406 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5406/
Java: 32bit/jdk1.8.0_66 -client -XX:+UseG1GC

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

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

Stack Trace:
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request.
at 
__randomizedtesting.SeedInfo.seed([61050EFB95C47A03:E95131213B3817FB]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1085)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:485)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:464)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1505)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:215)
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:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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 

[jira] [Commented] (LUCENE-6937) Migrate Lucene project from SVN to Git.

[Mark Miller (JIRA)]

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

Mark Miller commented on LUCENE-6937:
-

I filed INFRA-11056 Migrate Lucene project from SVN to Git.

> Migrate Lucene project from SVN to Git.
> ---
>
> Key: LUCENE-6937
> URL: https://issues.apache.org/jira/browse/LUCENE-6937
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>
> See mailing list discussion: 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201512.mbox/%3CCAL8PwkbFVT83ZbCZm0y-x-MDeTH6HYC_xYEjRev9fzzk5YXYmQ%40mail.gmail.com%3E



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

Moving Lucene / Solr from SVN to Git

[Mark Miller]

We have done almost all of the work necessary for a move and I have filed
an issue with INFRA.

LUCENE-6937: Migrate Lucene project from SVN to Git.
https://issues.apache.org/jira/browse/LUCENE-6937

INFRA-11056: Migrate Lucene project from SVN to Git.
https://issues.apache.org/jira/browse/INFRA-11056

Everyone knows about rebase and linear history right ;)

- Mark
-- 
- Mark
about.me/markrmiller

[jira] [Commented] (SOLR-8531) ZK leader path changed in 5.4

[Jeff Wartes (JIRA)]

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

Jeff Wartes commented on SOLR-8531:
---

I was imagining a note 
https://lucene.apache.org/solr/5_4_0/changes/Changes.html#v5.4.0.upgrading_from_solr_5.3
But I could understand that being driven off of an immutable release tag.

I haven't fully read the SOLR-7844 patch for comprehension, but the change to 
ZkStateReader.java looks like the reason:
https://github.com/apache/lucene-solr/commit/65cb72631b0833f8ddcf34dfa3d4a91f2c5091c4#diff-8f54b814c3da916328992910b1ad9163

I don't immediately see the change being necessary, so I suspect it could be 
reverted or made reverse-compatible without too much trouble.

If it's the former, then I'll presumably hit the same issue again in reverse 
moving from 5.4 to 5.4.1, which could be ok now that I know to expect it.


> ZK leader path changed in 5.4
> -
>
> Key: SOLR-8531
> URL: https://issues.apache.org/jira/browse/SOLR-8531
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4
>Reporter: Jeff Wartes
>
> While doing a rolling upgrade from 5.3 to 5.4 of a solrcloud cluster, I 
> observed that upgraded nodes would not register their shards as active unless 
> they were elected the leader for the shard.
> There were no errors, the shards were fully up and responsive, but would not  
> publish any change from the "down" state.
> This appears to be because the recovery process never happens, because the ZK 
> node containing the current leader can't be found, because the ZK path has 
> changed.
> Specifically, the leader data node changed from:
> /leaders/
> to
> /leaders//leader
> It looks to me like this happened during SOLR-7844, perhaps accidentally. 
> At the least, the "Migrating to Solr 5.4" section of the README should get 
> updated with this info, since it means a rolling upgrade of a collection with 
> multiple replicas will suffer serious degradation in the number of active 
> replicas as nodes are upgraded. It's entirely possible this will reduce some 
> shards to a single active replica.



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

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/432/

No tests ran.

Build Log:
[...truncated 53146 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (10.5 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.5.0-src.tgz...
   [smoker] 28.7 MB in 0.05 sec (619.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.5.0.tgz...
   [smoker] 63.4 MB in 0.09 sec (723.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.5.0.zip...
   [smoker] 73.8 MB in 0.10 sec (765.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.5.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6174 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6174 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.5.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6174 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6174 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.5.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 214 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 214 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (150.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-5.5.0-src.tgz...
   [smoker] 37.5 MB in 0.15 sec (256.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.5.0.tgz...
   [smoker] 130.2 MB in 0.18 sec (719.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.5.0.zip...
   [smoker] 138.1 MB in 0.19 sec (719.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-5.5.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-5.5.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 7 ...
   [smoker] test solr example w/ Java 7...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.0-java7/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 

[jira] [Commented] (SOLR-8480) Progress info for TupleStream

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8480:
--

The great thing about adding this to Streaming API, is that the Parallel SQL 
interface will get this also.

> Progress info for TupleStream
> -
>
> Key: SOLR-8480
> URL: https://issues.apache.org/jira/browse/SOLR-8480
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Cao Manh Dat
>
> I suggest adding progress info for TupleStream. It can be very helpful for 
> tracking consuming process
> {code}
> public abstract class TupleStream {
>public abstract long getSize();
>public abstract long getConsumed();
> }
> {code}



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

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

[jira] [Commented] (SOLR-7042) Enhance bin/post's JSON handling

[ASF subversion and git services (JIRA)]

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

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

Commit 1723879 from [~ehatcher] in branch 'dev/trunk'
[ https://svn.apache.org/r1723879 ]

SOLR-7042: bin/post defaults application/json to /update/json/docs now

> Enhance bin/post's JSON handling
> 
>
> Key: SOLR-7042
> URL: https://issues.apache.org/jira/browse/SOLR-7042
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.0
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: Trunk
>
> Attachments: SOLR-7042.patch
>
>
> The current (5.0) version of bin/post assumes JSON (and XML) are in *Solr* 
> command format, eg. {{bin/post -c collection1 data.json}} and that the URL to 
> post to is /update.  
> This issue is to improve/evolve bin/post so that it can post to /update when 
> the data is in *Solr* XML or JSON format and to /update/json/docs for 
> arbitrary JSON.



--
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-7042) Enhance bin/post's JSON handling

[ASF subversion and git services (JIRA)]

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

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

Commit 1723880 from [~ehatcher] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1723880 ]

SOLR-7042: bin/post defaults application/json to /update/json/docs now (merged 
from trunk r1723879)

> Enhance bin/post's JSON handling
> 
>
> Key: SOLR-7042
> URL: https://issues.apache.org/jira/browse/SOLR-7042
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.0
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: Trunk
>
> Attachments: SOLR-7042.patch
>
>
> The current (5.0) version of bin/post assumes JSON (and XML) are in *Solr* 
> command format, eg. {{bin/post -c collection1 data.json}} and that the URL to 
> post to is /update.  
> This issue is to improve/evolve bin/post so that it can post to /update when 
> the data is in *Solr* XML or JSON format and to /update/json/docs for 
> arbitrary JSON.



--
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-8531) ZK leader path changed in 5.4

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8531:
--

Jeff:

Thanks for 
1> persisting in figuring out what happened.
2> reporting it this comprehensively.

What did you do to fix this? I'm assuming that when the last old node is 
upgraded somebody takes over leadership and if not the FORCELEADER could fix 
that. And that if you aren't doing a rolling upgrade, i.e. you take the whole 
cluster down, upgrade and bring the whole cluster up there aren't any problems.

I agree that you shouldn't have to do either of the above, mostly just making 
sure I understand the ramifications.

[~markrmiller] any comments?



> ZK leader path changed in 5.4
> -
>
> Key: SOLR-8531
> URL: https://issues.apache.org/jira/browse/SOLR-8531
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4
>Reporter: Jeff Wartes
>
> While doing a rolling upgrade from 5.3 to 5.4 of a solrcloud cluster, I 
> observed that upgraded nodes would not register their shards as active unless 
> they were elected the leader for the shard.
> There were no errors, the shards were fully up and responsive, but would not  
> publish any change from the "down" state.
> This appears to be because the recovery process never happens, because the ZK 
> node containing the current leader can't be found, because the ZK path has 
> changed.
> Specifically, the leader data node changed from:
> /leaders/
> to
> /leaders//leader
> It looks to me like this happened during SOLR-7844, perhaps accidentally. 
> At the least, the "Migrating to Solr 5.4" section of the README should get 
> updated with this info, since it means a rolling upgrade of a collection with 
> multiple replicas will suffer serious degradation in the number of active 
> replicas as nodes are upgraded. It's entirely possible this will reduce some 
> shards to a single active replica.



--
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.x-Linux (64bit/jdk1.7.0_80) - Build # 15199 - Failure!

[Policeman Jenkins Server]

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

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

Error Message:
timed out waiting for collection1 startAt time to exceed: Sat Jan 09 11:27:20 
CST 2016

Stack Trace:
java.lang.AssertionError: timed out waiting for collection1 startAt time to 
exceed: Sat Jan 09 11:27:20 CST 2016
at 
__randomizedtesting.SeedInfo.seed([9A1AE5B10B858861:41B1E5770EADE1D2]: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: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:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




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

[jira] [Comment Edited] (SOLR-8492) Add LogisticRegressionQuery and LogitStream

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8492 at 1/9/16 5:47 PM:
--

[~caomanhdat], I pulled down your latest patch, read through it and ran the 
test case. It looks really good. Also the fact that the model is predicting 
probabilities correctly certainly is a good sign.

There are a few small things that I need to do to prepare this to be committed, 
but I'm planning on leaving your code basically as it is.

I'm sure there will be plenty of feedback on this as more people review the 
code and join the conversation. We can always adjust things based on this 
feedback.

We can also always have different implementations for if consensus is not 
reached on one single algorithm. But I think this is a great way to kick off 
the wider discussion.

Thanks for your help with this!


was (Author: joel.bernstein):
[~caomanhdat], I pulled down your latest patch, read through it and ran the 
test case. It looks really good. Also the fact that the model is predicting 
probabilities correctly certainly is a good sign.

There a few small things that I need to do to prepare this to be committed, but 
I'm planning on leaving your code basically as it is.

I'm sure there will be plenty of feedback on this as more people review the 
code and join the conversation. We can always adjust things based on this 
feedback.

We can also always have different implementations for if consensus is not 
reached on one single algorithm. But I think this is a great way to kick off 
the wider discussion.

Thanks for your help with this!

> Add LogisticRegressionQuery and LogitStream
> ---
>
> Key: SOLR-8492
> URL: https://issues.apache.org/jira/browse/SOLR-8492
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
> Attachments: SOLR-8492.patch, SOLR-8492.patch, SOLR-8492.patch
>
>
> This ticket is to add a new query called a LogisticRegressionQuery (LRQ).
> The LRQ extends AnalyticsQuery 
> (http://joelsolr.blogspot.com/2015/12/understanding-solrs-analyticsquery.html)
>  and returns a DelegatingCollector that implements a Stochastic Gradient 
> Descent (SGD) optimizer for Logistic Regression.
> This ticket also adds the LogitStream which leverages Streaming Expressions 
> to provide iteration over the shards. Each call to LogitStream.read() calls 
> down to the shards and executes the LogisticRegressionQuery. The model data 
> is collected from the shards and the weights are averaged and sent back to 
> the shards with the next iteration. Each call to read() returns a Tuple with 
> the averaged weights and error from the shards. With this approach the 
> LogitStream streams the changing model back to the client after each 
> iteration.
> The LogitStream will return the EOF Tuple when it reaches the defined 
> maxIterations. When sent as a Streaming Expression to the Stream handler this 
> provides parallel iterative behavior. This same approach can be used to 
> implement other parallel iterative algorithms.
> The initial patch has  a test which simply tests the mechanics of the 
> iteration. More work will need to be done to ensure the SGD is properly 
> implemented. The distributed approach of the SGD will also need to be 
> reviewed.  
> This implementation is designed for use cases with a small number of features 
> because each feature is it's own discreet field.
> An implementation which supports a higher number of features would be 
> possible by packing features into a byte array and storing as binary 
> DocValues.
> This implementation is designed to support a large sample set. With a large 
> number of shards, a sample set into the billions may be possible.
> sample Streaming Expression Syntax:
> {code}
> logit(collection1, features="a,b,c,d,e,f" outcome="x" maxIterations="80")
> {code}



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

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

[jira] [Commented] (SOLR-8492) Add LogisticRegressionQuery and LogitStream

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8492:
--

[~caomanhdat], I pulled down your latest patch, read through it and ran the 
test case. It looks really good. Also the fact that the model is predicting 
probabilities correctly certainly is a good sign.

There a few small things that I need to do to prepare this to be committed, but 
I'm planning on leaving your code basically as it is.

I'm sure there will be plenty of feedback on this as more people review the 
code and join the conversation. We can always adjust things based on this 
feedback.

We can also always have different implementations for if consensus is not 
reached on one single algorithm. But I think this is a great way to kick off 
the wider discussion.

Thanks for your help with this!

> Add LogisticRegressionQuery and LogitStream
> ---
>
> Key: SOLR-8492
> URL: https://issues.apache.org/jira/browse/SOLR-8492
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
> Attachments: SOLR-8492.patch, SOLR-8492.patch, SOLR-8492.patch
>
>
> This ticket is to add a new query called a LogisticRegressionQuery (LRQ).
> The LRQ extends AnalyticsQuery 
> (http://joelsolr.blogspot.com/2015/12/understanding-solrs-analyticsquery.html)
>  and returns a DelegatingCollector that implements a Stochastic Gradient 
> Descent (SGD) optimizer for Logistic Regression.
> This ticket also adds the LogitStream which leverages Streaming Expressions 
> to provide iteration over the shards. Each call to LogitStream.read() calls 
> down to the shards and executes the LogisticRegressionQuery. The model data 
> is collected from the shards and the weights are averaged and sent back to 
> the shards with the next iteration. Each call to read() returns a Tuple with 
> the averaged weights and error from the shards. With this approach the 
> LogitStream streams the changing model back to the client after each 
> iteration.
> The LogitStream will return the EOF Tuple when it reaches the defined 
> maxIterations. When sent as a Streaming Expression to the Stream handler this 
> provides parallel iterative behavior. This same approach can be used to 
> implement other parallel iterative algorithms.
> The initial patch has  a test which simply tests the mechanics of the 
> iteration. More work will need to be done to ensure the SGD is properly 
> implemented. The distributed approach of the SGD will also need to be 
> reviewed.  
> This implementation is designed for use cases with a small number of features 
> because each feature is it's own discreet field.
> An implementation which supports a higher number of features would be 
> possible by packing features into a byte array and storing as binary 
> DocValues.
> This implementation is designed to support a large sample set. With a large 
> number of shards, a sample set into the billions may be possible.
> sample Streaming Expression Syntax:
> {code}
> logit(collection1, features="a,b,c,d,e,f" outcome="x" maxIterations="80")
> {code}



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

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

[jira] [Commented] (SOLR-8480) Progress info for TupleStream

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8480:
--

I think this ticket will be important as we start to make the Streaming API 
more robust. I think something like a status bar with %complete would be doable.

As [~caomanhdat] mentioned we can get the count from the JSONTupleStream. From 
that we know how many documents there are to process and we can track how many 
documents have already been read.

The tricky part will be getting this information back to the client. One 
approach to this is to have the JSONTupleStream add the metrics to a JMX Bean 
on each worker. Then outside tools could gather up this information from each 
worker node and present a dashboard.

[~o...@apache.org], curious if you think this monitoring approach makes sense?

If we use this approach then this ticket would be about instrumenting the 
JSONTupleStream to gather the metrics.

> Progress info for TupleStream
> -
>
> Key: SOLR-8480
> URL: https://issues.apache.org/jira/browse/SOLR-8480
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Cao Manh Dat
>
> I suggest adding progress info for TupleStream. It can be very helpful for 
> tracking consuming process
> {code}
> public abstract class TupleStream {
>public abstract long getSize();
>public abstract long getConsumed();
> }
> {code}



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

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

[jira] [Comment Edited] (SOLR-8480) Progress info for TupleStream

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8480 at 1/9/16 6:27 PM:
--

The great thing about adding this to the Streaming API, is that the Parallel 
SQL interface will get this also.


was (Author: joel.bernstein):
The great thing about adding this to Streaming API, is that the Parallel SQL 
interface will get this also.

> Progress info for TupleStream
> -
>
> Key: SOLR-8480
> URL: https://issues.apache.org/jira/browse/SOLR-8480
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Cao Manh Dat
>
> I suggest adding progress info for TupleStream. It can be very helpful for 
> tracking consuming process
> {code}
> public abstract class TupleStream {
>public abstract long getSize();
>public abstract long getConsumed();
> }
> {code}



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

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

[jira] [Resolved] (SOLR-7042) Enhance bin/post's JSON handling

[Erik Hatcher (JIRA)]

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

Erik Hatcher resolved SOLR-7042.

   Resolution: Fixed
Fix Version/s: 5.5

Thanks [~shalinmangar]!   I committed with a couple of minor changes: added 
jsonl to the list in SPT and added example/exampledocs/more_books.jsonl to 
allow easy demonstration of jsonl in action.

> Enhance bin/post's JSON handling
> 
>
> Key: SOLR-7042
> URL: https://issues.apache.org/jira/browse/SOLR-7042
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.0
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-7042.patch
>
>
> The current (5.0) version of bin/post assumes JSON (and XML) are in *Solr* 
> command format, eg. {{bin/post -c collection1 data.json}} and that the URL to 
> post to is /update.  
> This issue is to improve/evolve bin/post so that it can post to /update when 
> the data is in *Solr* XML or JSON format and to /update/json/docs for 
> arbitrary JSON.



--
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-8468) Raise some test zk connection timeouts up from 10 seconds and remove some test timeout magic numbers.

[ASF subversion and git services (JIRA)]

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

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

Commit 1723888 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1723888 ]

SOLR-8468: Raise some test zk connection timeouts up from 10 seconds and remove 
some test timeout magic numbers.

> Raise some test zk connection timeouts up from 10 seconds and remove some 
> test timeout magic numbers.
> -
>
> Key: SOLR-8468
> URL: https://issues.apache.org/jira/browse/SOLR-8468
> Project: Solr
>  Issue Type: Test
>Reporter: Mark Miller
>Assignee: Mark Miller
>




--
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-8468) Raise some test zk connection timeouts up from 10 seconds and remove some test timeout magic numbers.

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-8468.
---
   Resolution: Fixed
Fix Version/s: Trunk
   5.5

> Raise some test zk connection timeouts up from 10 seconds and remove some 
> test timeout magic numbers.
> -
>
> Key: SOLR-8468
> URL: https://issues.apache.org/jira/browse/SOLR-8468
> Project: Solr
>  Issue Type: Test
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 5.5, Trunk
>
>




--
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-8468) Raise some test zk connection timeouts up from 10 seconds and remove some test timeout magic numbers.

[ASF subversion and git services (JIRA)]

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

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

Commit 1723889 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1723889 ]

SOLR-8468: Raise some test zk connection timeouts up from 10 seconds and remove 
some test timeout magic numbers.

> Raise some test zk connection timeouts up from 10 seconds and remove some 
> test timeout magic numbers.
> -
>
> Key: SOLR-8468
> URL: https://issues.apache.org/jira/browse/SOLR-8468
> Project: Solr
>  Issue Type: Test
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 5.5, Trunk
>
>




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

[Apache Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [TransactionLog]
at __randomizedtesting.SeedInfo.seed([38ADF1B04B4E27B6]: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:229)
at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source)
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$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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
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.HttpPartitionTest

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 3 object(s) that were not 
released!!! [RawDirectoryWrapper, RawDirectoryWrapper, RawDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([38ADF1B04B4E27B6]: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:229)
at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source)
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$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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

RE: Moving Lucene / Solr from SVN to Git

[Uwe Schindler]

Hi Mark,

 

thanks for starting this! Looking forward to the whole process. When Infra is 
about to “activate” the new GIT repo, I will take care of Policeman Jenkins and 
fix the remaining validation tasks. I don’t want to do this. I think your 
commit is fine.

 

We now need some workflows how to merge between master/trunk and the release 
branches. Projects do this in different ways (cherry-picking,…). I have no 
preference or idea, sorry! I only know how to merge feature branches into 
master :)

 

You mentioned that we should make the old svn read only. Maybe do it similar 
like we did during LuSolr merge: Add a final commit removing everything from 
trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x pointing 
to Git. All other branches stay alive. After that we could make it read only – 
but it is not really needed. What do others think?

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Mark Miller [mailto:markrmil...@gmail.com] 
Sent: Saturday, January 09, 2016 10:55 PM
To: java-dev 
Subject: Moving Lucene / Solr from SVN to Git

 

We have done almost all of the work necessary for a move and I have filed an 
issue with INFRA.

 

LUCENE-6937: Migrate Lucene project from SVN to Git.

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

 

INFRA-11056: Migrate Lucene project from SVN to Git.

https://issues.apache.org/jira/browse/INFRA-11056

 

Everyone knows about rebase and linear history right ;)

 

- Mark

-- 

- Mark 

about.me/markrmiller  

RE: Moving Lucene / Solr from SVN to Git

[Uwe Schindler]

Sorry:

 

> … I don’t want to do this. I think your commit is fine. …

 

I want to do this – of course, but not now. After the migration! :) Sorry, I 
was interrupted in the middle of sentence.

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Uwe Schindler [mailto:u...@thetaphi.de] 
Sent: Saturday, January 09, 2016 11:53 PM
To: dev@lucene.apache.org
Subject: RE: Moving Lucene / Solr from SVN to Git

 

Hi Mark,

 

thanks for starting this! Looking forward to the whole process. When Infra is 
about to “activate” the new GIT repo, I will take care of Policeman Jenkins and 
fix the remaining validation tasks. I don’t want to do this. I think your 
commit is fine.

 

We now need some workflows how to merge between master/trunk and the release 
branches. Projects do this in different ways (cherry-picking,…). I have no 
preference or idea, sorry! I only know how to merge feature branches into 
master :)

 

You mentioned that we should make the old svn read only. Maybe do it similar 
like we did during LuSolr merge: Add a final commit removing everything from 
trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x pointing 
to Git. All other branches stay alive. After that we could make it read only – 
but it is not really needed. What do others think?

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

  http://www.thetaphi.de

eMail:   u...@thetaphi.de

 

From: Mark Miller [  
mailto:markrmil...@gmail.com] 
Sent: Saturday, January 09, 2016 10:55 PM
To: java-dev <  java-...@lucene.apache.org>
Subject: Moving Lucene / Solr from SVN to Git

 

We have done almost all of the work necessary for a move and I have filed an 
issue with INFRA.

 

LUCENE-6937: Migrate Lucene project from SVN to Git.

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

 

INFRA-11056: Migrate Lucene project from SVN to Git.

https://issues.apache.org/jira/browse/INFRA-11056

 

Everyone knows about rebase and linear history right ;)

 

- Mark

-- 

- Mark 

about.me/markrmiller  

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

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-8097:
---

I'm gonna take a first pass at this.

Is the goal/hope for this JIRA that the builder will allow us to 
deprecate/remove the CloudSearchClient ctors?  (If so, should I remove them in 
this patch?)  Or is the hope just that this will prevent additional ctors from 
being needed in the future?

> 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: Trunk
>Reporter: Hrishikesh Gadre
>Priority: Minor
>
> 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

Re: Moving Lucene / Solr from SVN to Git

[Prasanna Dangalla]

On Sunday, 10 January 2016, Prasanna Dangalla 
wrote:

> Hi All,
> I'm a new member to this project. I was reading the mails previously.
> Thiught leeHere if we migrate
>
> mails previously. Thought of giving an input. Here if we migrate
>
Sorry for the typo...

>
> from svn its better to migrate the history as well. I meant the commit
> history. How do we migrate the SVN commit log from svn to git ?
>
> On Sunday, 10 January 2016, Mark Miller  > wrote:
>
>> I think we will update much of the doc as we go, but I'm sure there are
>> plenty of people that can help on the list with any questions. We can
>> probably get some basics up relatively painlessly. I'd guess the number of
>> committers that have not worked with Git yet is very small.
>>
>> As a start, my recommendation would be to Google Git for SVN users and
>> look at some of those resources though. It's probably better than what we
>> will subset.
>>
>> Personally, I like to just use SmartGit and mostly ignore command line
>> Git :)
>>
>> How have you been able to ignore GitHub for so long :)
>>
>> Mark
>> On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson 
>> wrote:
>>
>>> I'm a little confused. A while ago I asked about whether I had to
>>> learn all about Git, and as I remember the reply was "this is just
>>> about the build process". Perhaps I mis-interpreted or that was
>>> referring only to the bits Dawid was working on at that instant or
>>>
>>> Anyway, assuming the SVN repo becomes read-only, that implies that all
>>> our commits need to happen in Git, right? There are still some "git
>>> challenged" curmudgeons out there (like me) who really haven't much of
>>> a clue. I'll figure it out, mind you but it'd be nice if there were a
>>> clear signal that "Now you have to figure it out because you can't
>>> commit to the SVN repo any more".
>>>
>>> And the "how to contribute" page is all about SVN:
>>> https://wiki.apache.org/solr/HowToContribute, if my understanding is
>>> at all close that page needs some significant editing.
>>>
>>> Personally, before I screw up my first commit under Git, it would be
>>> super helpful if there were a step-by-step. No doubt that really
>>> amounts to three commands or something, but before "just trying stuff"
>>> it would be nice to have the steps for committing (pushing?) to trunk
>>> and then getting those changes into 5x (well, maybe 6.0 by then)
>>> outlined...
>>>
>>> Or I'm off in the weeds here, always a possibility.
>>>
>>> FWIW,
>>> Erick
>>>
>>>
>>>
>>> On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler  wrote:
>>> > Hi Mark,
>>> >
>>> >
>>> >
>>> > thanks for starting this! Looking forward to the whole process. When
>>> Infra
>>> > is about to “activate” the new GIT repo, I will take care of Policeman
>>> > Jenkins and fix the remaining validation tasks. I don’t want to do
>>> this. I
>>> > think your commit is fine.
>>> >
>>> >
>>> >
>>> > We now need some workflows how to merge between master/trunk and the
>>> release
>>> > branches. Projects do this in different ways (cherry-picking,…). I
>>> have no
>>> > preference or idea, sorry! I only know how to merge feature branches
>>> into
>>> > master J
>>> >
>>> >
>>> >
>>> > You mentioned that we should make the old svn read only. Maybe do it
>>> similar
>>> > like we did during LuSolr merge: Add a final commit removing
>>> everything from
>>> > trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x
>>> > pointing to Git. All other branches stay alive. After that we could
>>> make it
>>> > read only – but it is not really needed. What do others think?
>>> >
>>> >
>>> >
>>> > Uwe
>>> >
>>> >
>>> >
>>> > -
>>> >
>>> > Uwe Schindler
>>> >
>>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>>> >
>>> > http://www.thetaphi.de
>>> >
>>> > eMail: u...@thetaphi.de
>>> >
>>> >
>>> >
>>> > From: Mark Miller [mailto:markrmil...@gmail.com]
>>> > Sent: Saturday, January 09, 2016 10:55 PM
>>> > To: java-dev 
>>> > Subject: Moving Lucene / Solr from SVN to Git
>>> >
>>> >
>>> >
>>> > We have done almost all of the work necessary for a move and I have
>>> filed an
>>> > issue with INFRA.
>>> >
>>> >
>>> >
>>> > LUCENE-6937: Migrate Lucene project from SVN to Git.
>>> >
>>> > https://issues.apache.org/jira/browse/LUCENE-6937
>>> >
>>> >
>>> >
>>> > INFRA-11056: Migrate Lucene project from SVN to Git.
>>> >
>>> > https://issues.apache.org/jira/browse/INFRA-11056
>>> >
>>> >
>>> >
>>> > Everyone knows about rebase and linear history right ;)
>>> >
>>> >
>>> >
>>> > - Mark
>>> >
>>> > --
>>> >
>>> > - Mark
>>> >
>>> > about.me/markrmiller
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>> --
>> - Mark
>> about.me/markrmiller
>>
>
>

Re: Moving Lucene / Solr from SVN to Git

[Erick Erickson]

I'm a little confused. A while ago I asked about whether I had to
learn all about Git, and as I remember the reply was "this is just
about the build process". Perhaps I mis-interpreted or that was
referring only to the bits Dawid was working on at that instant or

Anyway, assuming the SVN repo becomes read-only, that implies that all
our commits need to happen in Git, right? There are still some "git
challenged" curmudgeons out there (like me) who really haven't much of
a clue. I'll figure it out, mind you but it'd be nice if there were a
clear signal that "Now you have to figure it out because you can't
commit to the SVN repo any more".

And the "how to contribute" page is all about SVN:
https://wiki.apache.org/solr/HowToContribute, if my understanding is
at all close that page needs some significant editing.

Personally, before I screw up my first commit under Git, it would be
super helpful if there were a step-by-step. No doubt that really
amounts to three commands or something, but before "just trying stuff"
it would be nice to have the steps for committing (pushing?) to trunk
and then getting those changes into 5x (well, maybe 6.0 by then)
outlined...

Or I'm off in the weeds here, always a possibility.

FWIW,
Erick



On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler  wrote:
> Hi Mark,
>
>
>
> thanks for starting this! Looking forward to the whole process. When Infra
> is about to “activate” the new GIT repo, I will take care of Policeman
> Jenkins and fix the remaining validation tasks. I don’t want to do this. I
> think your commit is fine.
>
>
>
> We now need some workflows how to merge between master/trunk and the release
> branches. Projects do this in different ways (cherry-picking,…). I have no
> preference or idea, sorry! I only know how to merge feature branches into
> master J
>
>
>
> You mentioned that we should make the old svn read only. Maybe do it similar
> like we did during LuSolr merge: Add a final commit removing everything from
> trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x
> pointing to Git. All other branches stay alive. After that we could make it
> read only – but it is not really needed. What do others think?
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: Mark Miller [mailto:markrmil...@gmail.com]
> Sent: Saturday, January 09, 2016 10:55 PM
> To: java-dev 
> Subject: Moving Lucene / Solr from SVN to Git
>
>
>
> We have done almost all of the work necessary for a move and I have filed an
> issue with INFRA.
>
>
>
> LUCENE-6937: Migrate Lucene project from SVN to Git.
>
> https://issues.apache.org/jira/browse/LUCENE-6937
>
>
>
> INFRA-11056: Migrate Lucene project from SVN to Git.
>
> https://issues.apache.org/jira/browse/INFRA-11056
>
>
>
> Everyone knows about rebase and linear history right ;)
>
>
>
> - Mark
>
> --
>
> - Mark
>
> about.me/markrmiller

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

Re: Moving Lucene / Solr from SVN to Git

[Mark Miller]

I think we will update much of the doc as we go, but I'm sure there are
plenty of people that can help on the list with any questions. We can
probably get some basics up relatively painlessly. I'd guess the number of
committers that have not worked with Git yet is very small.

As a start, my recommendation would be to Google Git for SVN users and look
at some of those resources though. It's probably better than what we will
subset.

Personally, I like to just use SmartGit and mostly ignore command line Git
:)

How have you been able to ignore GitHub for so long :)

Mark
On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson 
wrote:

> I'm a little confused. A while ago I asked about whether I had to
> learn all about Git, and as I remember the reply was "this is just
> about the build process". Perhaps I mis-interpreted or that was
> referring only to the bits Dawid was working on at that instant or
>
> Anyway, assuming the SVN repo becomes read-only, that implies that all
> our commits need to happen in Git, right? There are still some "git
> challenged" curmudgeons out there (like me) who really haven't much of
> a clue. I'll figure it out, mind you but it'd be nice if there were a
> clear signal that "Now you have to figure it out because you can't
> commit to the SVN repo any more".
>
> And the "how to contribute" page is all about SVN:
> https://wiki.apache.org/solr/HowToContribute, if my understanding is
> at all close that page needs some significant editing.
>
> Personally, before I screw up my first commit under Git, it would be
> super helpful if there were a step-by-step. No doubt that really
> amounts to three commands or something, but before "just trying stuff"
> it would be nice to have the steps for committing (pushing?) to trunk
> and then getting those changes into 5x (well, maybe 6.0 by then)
> outlined...
>
> Or I'm off in the weeds here, always a possibility.
>
> FWIW,
> Erick
>
>
>
> On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler  wrote:
> > Hi Mark,
> >
> >
> >
> > thanks for starting this! Looking forward to the whole process. When
> Infra
> > is about to “activate” the new GIT repo, I will take care of Policeman
> > Jenkins and fix the remaining validation tasks. I don’t want to do this.
> I
> > think your commit is fine.
> >
> >
> >
> > We now need some workflows how to merge between master/trunk and the
> release
> > branches. Projects do this in different ways (cherry-picking,…). I have
> no
> > preference or idea, sorry! I only know how to merge feature branches into
> > master J
> >
> >
> >
> > You mentioned that we should make the old svn read only. Maybe do it
> similar
> > like we did during LuSolr merge: Add a final commit removing everything
> from
> > trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x
> > pointing to Git. All other branches stay alive. After that we could make
> it
> > read only – but it is not really needed. What do others think?
> >
> >
> >
> > Uwe
> >
> >
> >
> > -
> >
> > Uwe Schindler
> >
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> >
> > http://www.thetaphi.de
> >
> > eMail: u...@thetaphi.de
> >
> >
> >
> > From: Mark Miller [mailto:markrmil...@gmail.com]
> > Sent: Saturday, January 09, 2016 10:55 PM
> > To: java-dev 
> > Subject: Moving Lucene / Solr from SVN to Git
> >
> >
> >
> > We have done almost all of the work necessary for a move and I have
> filed an
> > issue with INFRA.
> >
> >
> >
> > LUCENE-6937: Migrate Lucene project from SVN to Git.
> >
> > https://issues.apache.org/jira/browse/LUCENE-6937
> >
> >
> >
> > INFRA-11056: Migrate Lucene project from SVN to Git.
> >
> > https://issues.apache.org/jira/browse/INFRA-11056
> >
> >
> >
> > Everyone knows about rebase and linear history right ;)
> >
> >
> >
> > - Mark
> >
> > --
> >
> > - Mark
> >
> > about.me/markrmiller
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
- Mark
about.me/markrmiller

Re: Moving Lucene / Solr from SVN to Git

[Prasanna Dangalla]

Hi All,
I'm a new member to this project. I was reading the mails previously.
Thiught leeHere if we migrate from svn its better to migrate the history as
well. I meant the commit history. How do we migrate the SVN commit log from
svn to git ?

On Sunday, 10 January 2016, Mark Miller  wrote:

> I think we will update much of the doc as we go, but I'm sure there are
> plenty of people that can help on the list with any questions. We can
> probably get some basics up relatively painlessly. I'd guess the number of
> committers that have not worked with Git yet is very small.
>
> As a start, my recommendation would be to Google Git for SVN users and
> look at some of those resources though. It's probably better than what we
> will subset.
>
> Personally, I like to just use SmartGit and mostly ignore command line Git
> :)
>
> How have you been able to ignore GitHub for so long :)
>
> Mark
> On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson  > wrote:
>
>> I'm a little confused. A while ago I asked about whether I had to
>> learn all about Git, and as I remember the reply was "this is just
>> about the build process". Perhaps I mis-interpreted or that was
>> referring only to the bits Dawid was working on at that instant or
>>
>> Anyway, assuming the SVN repo becomes read-only, that implies that all
>> our commits need to happen in Git, right? There are still some "git
>> challenged" curmudgeons out there (like me) who really haven't much of
>> a clue. I'll figure it out, mind you but it'd be nice if there were a
>> clear signal that "Now you have to figure it out because you can't
>> commit to the SVN repo any more".
>>
>> And the "how to contribute" page is all about SVN:
>> https://wiki.apache.org/solr/HowToContribute, if my understanding is
>> at all close that page needs some significant editing.
>>
>> Personally, before I screw up my first commit under Git, it would be
>> super helpful if there were a step-by-step. No doubt that really
>> amounts to three commands or something, but before "just trying stuff"
>> it would be nice to have the steps for committing (pushing?) to trunk
>> and then getting those changes into 5x (well, maybe 6.0 by then)
>> outlined...
>>
>> Or I'm off in the weeds here, always a possibility.
>>
>> FWIW,
>> Erick
>>
>>
>>
>> On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler > > wrote:
>> > Hi Mark,
>> >
>> >
>> >
>> > thanks for starting this! Looking forward to the whole process. When
>> Infra
>> > is about to “activate” the new GIT repo, I will take care of Policeman
>> > Jenkins and fix the remaining validation tasks. I don’t want to do
>> this. I
>> > think your commit is fine.
>> >
>> >
>> >
>> > We now need some workflows how to merge between master/trunk and the
>> release
>> > branches. Projects do this in different ways (cherry-picking,…). I have
>> no
>> > preference or idea, sorry! I only know how to merge feature branches
>> into
>> > master J
>> >
>> >
>> >
>> > You mentioned that we should make the old svn read only. Maybe do it
>> similar
>> > like we did during LuSolr merge: Add a final commit removing everything
>> from
>> > trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x
>> > pointing to Git. All other branches stay alive. After that we could
>> make it
>> > read only – but it is not really needed. What do others think?
>> >
>> >
>> >
>> > Uwe
>> >
>> >
>> >
>> > -
>> >
>> > Uwe Schindler
>> >
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> >
>> > http://www.thetaphi.de
>> >
>> > eMail: u...@thetaphi.de
>> 
>> >
>> >
>> >
>> > From: Mark Miller [mailto:markrmil...@gmail.com
>> ]
>> > Sent: Saturday, January 09, 2016 10:55 PM
>> > To: java-dev > >
>> > Subject: Moving Lucene / Solr from SVN to Git
>> >
>> >
>> >
>> > We have done almost all of the work necessary for a move and I have
>> filed an
>> > issue with INFRA.
>> >
>> >
>> >
>> > LUCENE-6937: Migrate Lucene project from SVN to Git.
>> >
>> > https://issues.apache.org/jira/browse/LUCENE-6937
>> >
>> >
>> >
>> > INFRA-11056: Migrate Lucene project from SVN to Git.
>> >
>> > https://issues.apache.org/jira/browse/INFRA-11056
>> >
>> >
>> >
>> > Everyone knows about rebase and linear history right ;)
>> >
>> >
>> >
>> > - Mark
>> >
>> > --
>> >
>> > - Mark
>> >
>> > about.me/markrmiller
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
>>
>> --
> - Mark

Re: Moving Lucene / Solr from SVN to Git

[Steve Davids]

@Prasanna you can follow along with the SVN -> GIT history migration in 
https://issues.apache.org/jira/browse/LUCENE-6933 


@Erick for some basics you can checkout these interactive git guides, either 
https://www.codecademy.com/learn/learn-git 
 or http://gitreal.codeschool.com/ 
 though as Mark said if you find a decent UI 
you rarely need to use the command line. I’ve been fond of IntelliJ’s git 
support, but I have found Eclipse’s to be absolutely terrible (egit). 

-Steve

> On Jan 9, 2016, at 8:02 PM, Prasanna Dangalla  
> wrote:
> 
> 
> 
> On Sunday, 10 January 2016, Prasanna Dangalla  > wrote:
> Hi All,
> I'm a new member to this project. I was reading the mails previously. Thiught 
> leeHere if we migrate
> 
> mails previously. Thought of giving an input. Here if we migrate
> Sorry for the typo... 
> 
> from svn its better to migrate the history as well. I meant the commit 
> history. How do we migrate the SVN commit log from svn to git ? 
> 
> On Sunday, 10 January 2016, Mark Miller > wrote:
> I think we will update much of the doc as we go, but I'm sure there are 
> plenty of people that can help on the list with any questions. We can 
> probably get some basics up relatively painlessly. I'd guess the number of 
> committers that have not worked with Git yet is very small.
> 
> As a start, my recommendation would be to Google Git for SVN users and look 
> at some of those resources though. It's probably better than what we will 
> subset.
> 
> Personally, I like to just use SmartGit and mostly ignore command line Git :)
> 
> How have you been able to ignore GitHub for so long :)
> 
> Mark
> On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson > 
> wrote:
> I'm a little confused. A while ago I asked about whether I had to
> learn all about Git, and as I remember the reply was "this is just
> about the build process". Perhaps I mis-interpreted or that was
> referring only to the bits Dawid was working on at that instant or
> 
> Anyway, assuming the SVN repo becomes read-only, that implies that all
> our commits need to happen in Git, right? There are still some "git
> challenged" curmudgeons out there (like me) who really haven't much of
> a clue. I'll figure it out, mind you but it'd be nice if there were a
> clear signal that "Now you have to figure it out because you can't
> commit to the SVN repo any more".
> 
> And the "how to contribute" page is all about SVN:
> https://wiki.apache.org/solr/HowToContribute 
> , if my understanding is
> at all close that page needs some significant editing.
> 
> Personally, before I screw up my first commit under Git, it would be
> super helpful if there were a step-by-step. No doubt that really
> amounts to three commands or something, but before "just trying stuff"
> it would be nice to have the steps for committing (pushing?) to trunk
> and then getting those changes into 5x (well, maybe 6.0 by then)
> outlined...
> 
> Or I'm off in the weeds here, always a possibility.
> 
> FWIW,
> Erick
> 
> 
> 
> On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler > wrote:
> > Hi Mark,
> >
> >
> >
> > thanks for starting this! Looking forward to the whole process. When Infra
> > is about to “activate” the new GIT repo, I will take care of Policeman
> > Jenkins and fix the remaining validation tasks. I don’t want to do this. I
> > think your commit is fine.
> >
> >
> >
> > We now need some workflows how to merge between master/trunk and the release
> > branches. Projects do this in different ways (cherry-picking,…). I have no
> > preference or idea, sorry! I only know how to merge feature branches into
> > master J
> >
> >
> >
> > You mentioned that we should make the old svn read only. Maybe do it similar
> > like we did during LuSolr merge: Add a final commit removing everything from
> > trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x
> > pointing to Git. All other branches stay alive. After that we could make it
> > read only – but it is not really needed. What do others think?
> >
> >
> >
> > Uwe
> >
> >
> >
> > -
> >
> > Uwe Schindler
> >
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> >
> > http://www.thetaphi.de 
> >
> > eMail: u...@thetaphi.de <>
> >
> >
> >
> > From: Mark Miller [mailto:markrmil...@gmail.com <>]
> > Sent: Saturday, January 09, 2016 10:55 PM
> > To: java-dev >
> > Subject: Moving Lucene / Solr from SVN to Git
> >
> >
> >
> > We have done almost all of the work necessary for a move and I have filed an
> > issue with INFRA.
> >
> >
> >
> > LUCENE-6937: Migrate Lucene project from SVN to Git.
> >
> > https://issues.apache.org/jira/browse/LUCENE-6937 

Re: Moving Lucene / Solr from SVN to Git

[Erick Erickson]

bq: How have you been able to ignore GitHub for so long :)

Willful ignorance and not being forced to ;)

I already have the "Git for SVN users" and similar. They're kinda
helpful but I'm still flying blind. I mean apparently "git cherry-pick
rev" is equivalent to the merge command I've been using to merge trunk
changes into 5x.

The key here is "apparently". It would be comforting to know what
others do that works in our (future) environment before taking
"somebody's blog's" word for it.

Although I guess we're all really flying blind in that so far the
people who use the Git repo still have to merge via SVN to get code
committed.

Anyway, it'll work out I'm sure.

Prasanna:

The history question has been discussed at some length, here's a place
to start reviewing what's been done so far:
https://issues.apache.org/jira/browse/LUCENE-6933

Best,
Erick

On Sat, Jan 9, 2016 at 4:40 PM, Mark Miller  wrote:
> I think we will update much of the doc as we go, but I'm sure there are
> plenty of people that can help on the list with any questions. We can
> probably get some basics up relatively painlessly. I'd guess the number of
> committers that have not worked with Git yet is very small.
>
> As a start, my recommendation would be to Google Git for SVN users and look
> at some of those resources though. It's probably better than what we will
> subset.
>
> Personally, I like to just use SmartGit and mostly ignore command line Git
> :)
>
> How have you been able to ignore GitHub for so long :)
>
> Mark
> On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson 
> wrote:
>>
>> I'm a little confused. A while ago I asked about whether I had to
>> learn all about Git, and as I remember the reply was "this is just
>> about the build process". Perhaps I mis-interpreted or that was
>> referring only to the bits Dawid was working on at that instant or
>>
>> Anyway, assuming the SVN repo becomes read-only, that implies that all
>> our commits need to happen in Git, right? There are still some "git
>> challenged" curmudgeons out there (like me) who really haven't much of
>> a clue. I'll figure it out, mind you but it'd be nice if there were a
>> clear signal that "Now you have to figure it out because you can't
>> commit to the SVN repo any more".
>>
>> And the "how to contribute" page is all about SVN:
>> https://wiki.apache.org/solr/HowToContribute, if my understanding is
>> at all close that page needs some significant editing.
>>
>> Personally, before I screw up my first commit under Git, it would be
>> super helpful if there were a step-by-step. No doubt that really
>> amounts to three commands or something, but before "just trying stuff"
>> it would be nice to have the steps for committing (pushing?) to trunk
>> and then getting those changes into 5x (well, maybe 6.0 by then)
>> outlined...
>>
>> Or I'm off in the weeds here, always a possibility.
>>
>> FWIW,
>> Erick
>>
>>
>>
>> On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler  wrote:
>> > Hi Mark,
>> >
>> >
>> >
>> > thanks for starting this! Looking forward to the whole process. When
>> > Infra
>> > is about to “activate” the new GIT repo, I will take care of Policeman
>> > Jenkins and fix the remaining validation tasks. I don’t want to do this.
>> > I
>> > think your commit is fine.
>> >
>> >
>> >
>> > We now need some workflows how to merge between master/trunk and the
>> > release
>> > branches. Projects do this in different ways (cherry-picking,…). I have
>> > no
>> > preference or idea, sorry! I only know how to merge feature branches
>> > into
>> > master J
>> >
>> >
>> >
>> > You mentioned that we should make the old svn read only. Maybe do it
>> > similar
>> > like we did during LuSolr merge: Add a final commit removing everything
>> > from
>> > trunk/branch_5x and leaving a readme.txt file in trunk and branch_5x
>> > pointing to Git. All other branches stay alive. After that we could make
>> > it
>> > read only – but it is not really needed. What do others think?
>> >
>> >
>> >
>> > Uwe
>> >
>> >
>> >
>> > -
>> >
>> > Uwe Schindler
>> >
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> >
>> > http://www.thetaphi.de
>> >
>> > eMail: u...@thetaphi.de
>> >
>> >
>> >
>> > From: Mark Miller [mailto:markrmil...@gmail.com]
>> > Sent: Saturday, January 09, 2016 10:55 PM
>> > To: java-dev 
>> > Subject: Moving Lucene / Solr from SVN to Git
>> >
>> >
>> >
>> > We have done almost all of the work necessary for a move and I have
>> > filed an
>> > issue with INFRA.
>> >
>> >
>> >
>> > LUCENE-6937: Migrate Lucene project from SVN to Git.
>> >
>> > https://issues.apache.org/jira/browse/LUCENE-6937
>> >
>> >
>> >
>> > INFRA-11056: Migrate Lucene project from SVN to Git.
>> >
>> > https://issues.apache.org/jira/browse/INFRA-11056
>> >
>> >
>> >
>> > Everyone knows about rebase and linear history right ;)
>> >
>> >
>> >
>> > - Mark
>> >
>> > --
>> >
>> > - Mark
>> >
>> > 

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

[Policeman Jenkins Server]

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

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

Error Message:
Didn't see all replicas for shard shard1 in c8n_1x2 come up within 3 ms! 
ClusterState: {   "collection1":{ "replicationFactor":"1", "shards":{   
"shard1":{ "range":"8000-", "state":"active",   
  "replicas":{"core_node2":{ "core":"collection1", 
"base_url":"http://127.0.0.1:45602;, 
"node_name":"127.0.0.1:45602_", "state":"active", 
"leader":"true"}}},   "shard2":{ "range":"0-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"collection1", "base_url":"http://127.0.0.1:40878;,  
   "node_name":"127.0.0.1:40878_", "state":"active", 
"leader":"true"},   "core_node3":{ "core":"collection1",
 "base_url":"http://127.0.0.1:45045;, 
"node_name":"127.0.0.1:45045_", "state":"active", 
"router":{"name":"compositeId"}, "maxShardsPerNode":"1", 
"autoAddReplicas":"false", "autoCreated":"true"},   "control_collection":{  
   "replicationFactor":"1", "shards":{"shard1":{ 
"range":"8000-7fff", "state":"active", 
"replicas":{"core_node1":{ "core":"collection1", 
"base_url":"http://127.0.0.1:58979;, 
"node_name":"127.0.0.1:58979_", "state":"active", 
"leader":"true", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false", 
"autoCreated":"true"},   "c8n_1x2":{ "replicationFactor":"2", 
"shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"c8n_1x2_shard1_replica2", 
"base_url":"http://127.0.0.1:58979;, 
"node_name":"127.0.0.1:58979_", "state":"recovering"},   
"core_node2":{ "core":"c8n_1x2_shard1_replica1", 
"base_url":"http://127.0.0.1:45602;, 
"node_name":"127.0.0.1:45602_", "state":"active", 
"leader":"true", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false"},   "collMinRf_1x3":{ 
"replicationFactor":"3", "shards":{"shard1":{ 
"range":"8000-7fff", "state":"active", "replicas":{ 
  "core_node1":{ "core":"collMinRf_1x3_shard1_replica1",
 "base_url":"http://127.0.0.1:58979;, 
"node_name":"127.0.0.1:58979_", "state":"active"},   
"core_node2":{ "core":"collMinRf_1x3_shard1_replica2", 
"base_url":"http://127.0.0.1:45045;, 
"node_name":"127.0.0.1:45045_", "state":"active"},   
"core_node3":{ "core":"collMinRf_1x3_shard1_replica3", 
"base_url":"http://127.0.0.1:40878;, 
"node_name":"127.0.0.1:40878_", "state":"active", 
"leader":"true", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false"}}

Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in c8n_1x2 
come up within 3 ms! ClusterState: {
  "collection1":{
"replicationFactor":"1",
"shards":{
  "shard1":{
"range":"8000-",
"state":"active",
"replicas":{"core_node2":{
"core":"collection1",
"base_url":"http://127.0.0.1:45602;,
"node_name":"127.0.0.1:45602_",
"state":"active",
"leader":"true"}}},
  "shard2":{
"range":"0-7fff",
"state":"active",
"replicas":{
  "core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:40878;,
"node_name":"127.0.0.1:40878_",
"state":"active",
"leader":"true"},
  "core_node3":{
"core":"collection1",
"base_url":"http://127.0.0.1:45045;,
"node_name":"127.0.0.1:45045_",
"state":"active",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"autoCreated":"true"},
  "control_collection":{
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:58979;,
"node_name":"127.0.0.1:58979_",
"state":"active",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"autoCreated":"true"},
  

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15499/
Java: 64bit/jdk-9-ea+95 -XX:+UseCompressedOops -XX:+UseG1GC -XX:-CompactStrings

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=9971, 
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:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 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:747)2) Thread[id=9968, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)3) Thread[id=9972, 
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:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 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:747)4) Thread[id=9970, 
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:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 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:747)5) Thread[id=9969, 
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:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 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:747)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=9971, 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:218)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
at 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15501/
Java: 32bit/jdk-9-ea+95 -client -XX:+UseSerialGC -XX:-CompactStrings

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

Error Message:
Didn't see all replicas for shard shard1 in c8n_1x2 come up within 3 ms! 
ClusterState: {   "collection1":{ "replicationFactor":"1", "shards":{   
"shard1":{ "range":"8000-", "state":"active",   
  "replicas":{"core_node2":{ "core":"collection1", 
"base_url":"http://127.0.0.1:46916/zou/xu;, 
"node_name":"127.0.0.1:46916_zou%2Fxu", "state":"active",   
  "leader":"true"}}},   "shard2":{ "range":"0-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"collection1", "base_url":"http://127.0.0.1:45496/zou/xu;,   
  "node_name":"127.0.0.1:45496_zou%2Fxu", "state":"active", 
"leader":"true"},   "core_node3":{ 
"core":"collection1", "base_url":"http://127.0.0.1:60472/zou/xu;,   
  "node_name":"127.0.0.1:60472_zou%2Fxu", 
"state":"active", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false", 
"autoCreated":"true"},   "control_collection":{ "replicationFactor":"1",
 "shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{"core_node1":{ 
"core":"collection1", "base_url":"http://127.0.0.1:58822/zou/xu;,   
  "node_name":"127.0.0.1:58822_zou%2Fxu", "state":"active", 
"leader":"true", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false", 
"autoCreated":"true"},   "c8n_1x2":{ "replicationFactor":"2", 
"shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"c8n_1x2_shard1_replica1", 
"base_url":"http://127.0.0.1:60472/zou/xu;, 
"node_name":"127.0.0.1:60472_zou%2Fxu", "state":"active",   
  "leader":"true"},   "core_node2":{ 
"core":"c8n_1x2_shard1_replica2", 
"base_url":"http://127.0.0.1:45496/zou/xu;, 
"node_name":"127.0.0.1:45496_zou%2Fxu", "state":"recovering",   
  "router":{"name":"compositeId"}, "maxShardsPerNode":"1", 
"autoAddReplicas":"false"},   "collMinRf_1x3":{ "replicationFactor":"3",
 "shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"collMinRf_1x3_shard1_replica3", 
"base_url":"http://127.0.0.1:45496/zou/xu;, 
"node_name":"127.0.0.1:45496_zou%2Fxu", "state":"active",   
  "leader":"true"},   "core_node2":{ 
"core":"collMinRf_1x3_shard1_replica2", 
"base_url":"http://127.0.0.1:46916/zou/xu;, 
"node_name":"127.0.0.1:46916_zou%2Fxu", "state":"active"},  
 "core_node3":{ "core":"collMinRf_1x3_shard1_replica1", 
"base_url":"http://127.0.0.1:60472/zou/xu;, 
"node_name":"127.0.0.1:60472_zou%2Fxu", "state":"active", 
"router":{"name":"compositeId"}, "maxShardsPerNode":"1", 
"autoAddReplicas":"false"}}

Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in c8n_1x2 
come up within 3 ms! ClusterState: {
  "collection1":{
"replicationFactor":"1",
"shards":{
  "shard1":{
"range":"8000-",
"state":"active",
"replicas":{"core_node2":{
"core":"collection1",
"base_url":"http://127.0.0.1:46916/zou/xu;,
"node_name":"127.0.0.1:46916_zou%2Fxu",
"state":"active",
"leader":"true"}}},
  "shard2":{
"range":"0-7fff",
"state":"active",
"replicas":{
  "core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:45496/zou/xu;,
"node_name":"127.0.0.1:45496_zou%2Fxu",
"state":"active",
"leader":"true"},
  "core_node3":{
"core":"collection1",
"base_url":"http://127.0.0.1:60472/zou/xu;,
"node_name":"127.0.0.1:60472_zou%2Fxu",
"state":"active",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"autoCreated":"true"},
  "control_collection":{
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:58822/zou/xu;,

[jira] [Updated] (LUCENE-6969) Exception in reading SortedDocValues

[John Wang (JIRA)]

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

John Wang updated LUCENE-6969:
--
Description: 
While reading SortedDocValues, I am getting the following stacktrace:
{noformat}
Exception in thread "main" java.lang.IndexOutOfBoundsException
at java.nio.Buffer.checkIndex(Buffer.java:546)
at java.nio.DirectByteBuffer.getShort(DirectByteBuffer.java:590)
at 
org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl.readShort(ByteBufferIndexInput.java:443)
at 
org.apache.lucene.util.packed.DirectReader$DirectPackedReader16.get(DirectReader.java:185)
at 
org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$2.get(Lucene54DocValuesProducer.java:502)
at org.apache.lucene.util.LongValues.get(LongValues.java:45)
at 
org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$7.getOrd(Lucene54DocValuesProducer.java:800)
{noformat}

I am not able to reproduce with a unit test. However, I am able to consistently 
reproduce it with my data. I think this is some sort of off-by-one error caused 
with my index.

I am happy to provide my index for reproduce this offline.

Here is the code snippet:
{noformat}
public static void main(String[] args) throws Exception {
File idx = new File("/tmp/myidx");
int id = 719265;
Path idxPath = FileSystems.getDefault().getPath(idx.getAbsolutePath());
FSDirectory dir = FSDirectory.open(idxPath);
DirectoryReader dreader = DirectoryReader.open(dir);
LeafReaderContext ctx = dreader.leaves().get(0);

SortedDocValues docVal = ctx.reader().getSortedDocValues("host");
int ord = docVal.getOrd(id);
System.out.println("ord: " + ord);

  }
{noformat}

My index has 1 segment and 5M docs.

  was:
While reading SortedDocValues, I am getting the following stacktrace:
{noformat}
Exception in thread "main" java.lang.IndexOutOfBoundsException
at java.nio.Buffer.checkIndex(Buffer.java:546)
at java.nio.DirectByteBuffer.getShort(DirectByteBuffer.java:590)
at 
org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl.readShort(ByteBufferIndexInput.java:443)
at 
org.apache.lucene.util.packed.DirectReader$DirectPackedReader16.get(DirectReader.java:185)
at 
org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$2.get(Lucene54DocValuesProducer.java:502)
at org.apache.lucene.util.LongValues.get(LongValues.java:45)
at 
org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$7.getOrd(Lucene54DocValuesProducer.java:800)
{noformat}

I am not able to reproduce with a unit test. However, I am able to consistently 
reproduce it with my data. I think this is some sort of off-by-one error caused 
with my index.

I am happy to provide my index for reproduce this offline.

Here is the code snippet:
{noformat}
public static void main(String[] args) throws Exception {
File idx = new File("/tmp/rapid/data/1448008627000_1448120881000");
int id = 719265;
Path idxPath = FileSystems.getDefault().getPath(idx.getAbsolutePath());
FSDirectory dir = FSDirectory.open(idxPath);
DirectoryReader dreader = DirectoryReader.open(dir);
LeafReaderContext ctx = dreader.leaves().get(0);

SortedDocValues docVal = ctx.reader().getSortedDocValues("host");
int ord = docVal.getOrd(id);
System.out.println("ord: " + ord);

  }
{noformat}

My index has 1 segment and 5M docs.


> Exception in reading SortedDocValues
> 
>
> Key: LUCENE-6969
> URL: https://issues.apache.org/jira/browse/LUCENE-6969
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 5.4
>Reporter: John Wang
>
> While reading SortedDocValues, I am getting the following stacktrace:
> {noformat}
> Exception in thread "main" java.lang.IndexOutOfBoundsException
>   at java.nio.Buffer.checkIndex(Buffer.java:546)
>   at java.nio.DirectByteBuffer.getShort(DirectByteBuffer.java:590)
>   at 
> org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl.readShort(ByteBufferIndexInput.java:443)
>   at 
> org.apache.lucene.util.packed.DirectReader$DirectPackedReader16.get(DirectReader.java:185)
>   at 
> org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$2.get(Lucene54DocValuesProducer.java:502)
>   at org.apache.lucene.util.LongValues.get(LongValues.java:45)
>   at 
> org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$7.getOrd(Lucene54DocValuesProducer.java:800)
> {noformat}
> I am not able to reproduce with a unit test. However, I am able to 
> consistently reproduce it with my data. I think this is some sort of 
> off-by-one error caused with my index.
> I am happy to provide my index for reproduce this offline.
> Here is the code snippet:
> {noformat}
> public 

[jira] [Updated] (LUCENE-6969) Exception in reading SortedDocValues

[John Wang (JIRA)]

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

John Wang updated LUCENE-6969:
--
Description: 
While reading SortedDocValues, I am getting the following stacktrace:
{noformat}
Exception in thread "main" java.lang.IndexOutOfBoundsException
at java.nio.Buffer.checkIndex(Buffer.java:546)
at java.nio.DirectByteBuffer.getShort(DirectByteBuffer.java:590)
at 
org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl.readShort(ByteBufferIndexInput.java:443)
at 
org.apache.lucene.util.packed.DirectReader$DirectPackedReader16.get(DirectReader.java:185)
at 
org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$2.get(Lucene54DocValuesProducer.java:502)
at org.apache.lucene.util.LongValues.get(LongValues.java:45)
at 
org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$7.getOrd(Lucene54DocValuesProducer.java:800)
{noformat}

I am not able to reproduce with a unit test. However, I am able to consistently 
reproduce it with my data. I think this is some sort of off-by-one error caused 
with my index.

I am happy to provide my index to help debug this offline.

Here is the code snippet:
{noformat}
public static void main(String[] args) throws Exception {
File idx = new File("/tmp/myidx");
int id = 719265;
Path idxPath = FileSystems.getDefault().getPath(idx.getAbsolutePath());
FSDirectory dir = FSDirectory.open(idxPath);
DirectoryReader dreader = DirectoryReader.open(dir);
LeafReaderContext ctx = dreader.leaves().get(0);

SortedDocValues docVal = ctx.reader().getSortedDocValues("host");
int ord = docVal.getOrd(id);
System.out.println("ord: " + ord);

  }
{noformat}

My index has 1 segment and 5M docs.

  was:
While reading SortedDocValues, I am getting the following stacktrace:
{noformat}
Exception in thread "main" java.lang.IndexOutOfBoundsException
at java.nio.Buffer.checkIndex(Buffer.java:546)
at java.nio.DirectByteBuffer.getShort(DirectByteBuffer.java:590)
at 
org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl.readShort(ByteBufferIndexInput.java:443)
at 
org.apache.lucene.util.packed.DirectReader$DirectPackedReader16.get(DirectReader.java:185)
at 
org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$2.get(Lucene54DocValuesProducer.java:502)
at org.apache.lucene.util.LongValues.get(LongValues.java:45)
at 
org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$7.getOrd(Lucene54DocValuesProducer.java:800)
{noformat}

I am not able to reproduce with a unit test. However, I am able to consistently 
reproduce it with my data. I think this is some sort of off-by-one error caused 
with my index.

I am happy to provide my index for reproduce this offline.

Here is the code snippet:
{noformat}
public static void main(String[] args) throws Exception {
File idx = new File("/tmp/myidx");
int id = 719265;
Path idxPath = FileSystems.getDefault().getPath(idx.getAbsolutePath());
FSDirectory dir = FSDirectory.open(idxPath);
DirectoryReader dreader = DirectoryReader.open(dir);
LeafReaderContext ctx = dreader.leaves().get(0);

SortedDocValues docVal = ctx.reader().getSortedDocValues("host");
int ord = docVal.getOrd(id);
System.out.println("ord: " + ord);

  }
{noformat}

My index has 1 segment and 5M docs.


> Exception in reading SortedDocValues
> 
>
> Key: LUCENE-6969
> URL: https://issues.apache.org/jira/browse/LUCENE-6969
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 5.4
>Reporter: John Wang
>
> While reading SortedDocValues, I am getting the following stacktrace:
> {noformat}
> Exception in thread "main" java.lang.IndexOutOfBoundsException
>   at java.nio.Buffer.checkIndex(Buffer.java:546)
>   at java.nio.DirectByteBuffer.getShort(DirectByteBuffer.java:590)
>   at 
> org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl.readShort(ByteBufferIndexInput.java:443)
>   at 
> org.apache.lucene.util.packed.DirectReader$DirectPackedReader16.get(DirectReader.java:185)
>   at 
> org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$2.get(Lucene54DocValuesProducer.java:502)
>   at org.apache.lucene.util.LongValues.get(LongValues.java:45)
>   at 
> org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$7.getOrd(Lucene54DocValuesProducer.java:800)
> {noformat}
> I am not able to reproduce with a unit test. However, I am able to 
> consistently reproduce it with my data. I think this is some sort of 
> off-by-one error caused with my index.
> I am happy to provide my index to help debug this offline.
> Here is the code snippet:
> {noformat}
> public static void main(String[] args) 

[jira] [Created] (LUCENE-6969) Exception in reading SortedDocValues

[John Wang (JIRA)]

John Wang created LUCENE-6969:
-

 Summary: Exception in reading SortedDocValues
 Key: LUCENE-6969
 URL: https://issues.apache.org/jira/browse/LUCENE-6969
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 5.4
Reporter: John Wang


While reading SortedDocValues, I am getting the following stacktrace:
{noformat}
Exception in thread "main" java.lang.IndexOutOfBoundsException
at java.nio.Buffer.checkIndex(Buffer.java:546)
at java.nio.DirectByteBuffer.getShort(DirectByteBuffer.java:590)
at 
org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl.readShort(ByteBufferIndexInput.java:443)
at 
org.apache.lucene.util.packed.DirectReader$DirectPackedReader16.get(DirectReader.java:185)
at 
org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$2.get(Lucene54DocValuesProducer.java:502)
at org.apache.lucene.util.LongValues.get(LongValues.java:45)
at 
org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$7.getOrd(Lucene54DocValuesProducer.java:800)
{noformat}

I am not able to reproduce with a unit test. However, I am able to consistently 
reproduce it with my data. I think this is some sort of off-by-one error caused 
with my index.

I am happy to provide my index for reproduce this offline.

Here is the code snippet:
{noformat}
public static void main(String[] args) throws Exception {
File idx = new File("/tmp/rapid/data/1448008627000_1448120881000");
int id = 719265;
Path idxPath = FileSystems.getDefault().getPath(idx.getAbsolutePath());
FSDirectory dir = FSDirectory.open(idxPath);
DirectoryReader dreader = DirectoryReader.open(dir);
LeafReaderContext ctx = dreader.leaves().get(0);

SortedDocValues docVal = ctx.reader().getSortedDocValues("host");
int ord = docVal.getOrd(id);
System.out.println("ord: " + ord);

  }
{noformat}

My index has 1 segment and 5M docs.



--
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] [Closed] (LUCENE-6969) Exception in reading SortedDocValues

[John Wang (JIRA)]

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

John Wang closed LUCENE-6969.
-
Resolution: Invalid

False alarm. My index had multiple segments, and the docid sits on the border, 
causing the exception.

> Exception in reading SortedDocValues
> 
>
> Key: LUCENE-6969
> URL: https://issues.apache.org/jira/browse/LUCENE-6969
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 5.4
>Reporter: John Wang
>
> While reading SortedDocValues, I am getting the following stacktrace:
> {noformat}
> Exception in thread "main" java.lang.IndexOutOfBoundsException
>   at java.nio.Buffer.checkIndex(Buffer.java:546)
>   at java.nio.DirectByteBuffer.getShort(DirectByteBuffer.java:590)
>   at 
> org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl.readShort(ByteBufferIndexInput.java:443)
>   at 
> org.apache.lucene.util.packed.DirectReader$DirectPackedReader16.get(DirectReader.java:185)
>   at 
> org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$2.get(Lucene54DocValuesProducer.java:502)
>   at org.apache.lucene.util.LongValues.get(LongValues.java:45)
>   at 
> org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$7.getOrd(Lucene54DocValuesProducer.java:800)
> {noformat}
> I am not able to reproduce with a unit test. However, I am able to 
> consistently reproduce it with my data. I think this is some sort of 
> off-by-one error caused with my index.
> I am happy to provide my index to help debug this offline.
> Here is the code snippet:
> {noformat}
> public static void main(String[] args) throws Exception {
> File idx = new File("/tmp/myidx");
> int id = 719265;
> Path idxPath = FileSystems.getDefault().getPath(idx.getAbsolutePath());
> FSDirectory dir = FSDirectory.open(idxPath);
> DirectoryReader dreader = DirectoryReader.open(dir);
> LeafReaderContext ctx = dreader.leaves().get(0);
> 
> SortedDocValues docVal = ctx.reader().getSortedDocValues("host");
> int ord = docVal.getOrd(id);
> System.out.println("ord: " + ord);
> 
>   }
> {noformat}
> My index has 1 segment and 5M docs.



--
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-6938) Convert build to work with Git rather than SVN.

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-6938:
-

bq. I think I slightly misunderstood this the first time. You meant making it 
more efficient for windows was not a requirement?

Yes, exactly. I work on Windows so it also affects me, but I don't think it's 
critical.

bq. It does not look so easy though

I think it's doable, but far from convenient. It's a similar situation as to 
what happens with "checking whether any tests executed" -- you want a property 
or a marked passed down to sub-builds... it's a pain to maintain. Perhaps we 
should look at the core of the problem and somehow fix it in any itself...

> Convert build to work with Git rather than SVN.
> ---
>
> Key: LUCENE-6938
> URL: https://issues.apache.org/jira/browse/LUCENE-6938
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: LUCENE-6938.patch
>
>
> We assume an SVN checkout in parts of our build and will need to move to 
> assuming a Git checkout.
> Patches against https://github.com/dweiss/lucene-solr-svn2git from 
> LUCENE-6933.



--
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] (LUCENE-6938) Convert build to work with Git rather than SVN.

[Dawid Weiss (JIRA)]

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

Dawid Weiss edited comment on LUCENE-6938 at 1/9/16 8:12 AM:
-

bq. I think I slightly misunderstood this the first time. You meant making it 
more efficient for windows was not a requirement?

Yes, exactly. I work on Windows so it also affects me, but I don't think it's 
critical.

bq. It does not look so easy though

I think it's doable, but far from convenient. It's a similar situation as to 
what happens with "checking whether any tests executed" -- you want a property 
or a marked passed down to sub-builds... it's a pain to maintain. Perhaps we 
should look at the core of the problem and somehow fix it in Ant itself...


was (Author: dweiss):
bq. I think I slightly misunderstood this the first time. You meant making it 
more efficient for windows was not a requirement?

Yes, exactly. I work on Windows so it also affects me, but I don't think it's 
critical.

bq. It does not look so easy though

I think it's doable, but far from convenient. It's a similar situation as to 
what happens with "checking whether any tests executed" -- you want a property 
or a marked passed down to sub-builds... it's a pain to maintain. Perhaps we 
should look at the core of the problem and somehow fix it in any itself...

> Convert build to work with Git rather than SVN.
> ---
>
> Key: LUCENE-6938
> URL: https://issues.apache.org/jira/browse/LUCENE-6938
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: LUCENE-6938.patch
>
>
> We assume an SVN checkout in parts of our build and will need to move to 
> assuming a Git checkout.
> Patches against https://github.com/dweiss/lucene-solr-svn2git from 
> LUCENE-6933.



--
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-8531) ZK leader path changed in 5.4

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8531:


[~jwartes], what README information are you thinking should be updated?  If 
it's one of the text files included in the download, those can't change.  A 
5.4.1 release would need to be made.

Assuming that the path change wasn't necessary for some functionality in 
SOLR-7844, I think we should revert the change and push a 5.4.1 release out as 
quickly as possible.  Alternately (assuming it's even possible), 5.4.1 could 
detect older releases in the cluster and work in a compatibility mode.

> ZK leader path changed in 5.4
> -
>
> Key: SOLR-8531
> URL: https://issues.apache.org/jira/browse/SOLR-8531
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4
>Reporter: Jeff Wartes
>
> While doing a rolling upgrade from 5.3 to 5.4 of a solrcloud cluster, I 
> observed that upgraded nodes would not register their shards as active unless 
> they were elected the leader for the shard.
> There were no errors, the shards were fully up and responsive, but would not  
> publish any change from the "down" state.
> This appears to be because the recovery process never happens, because the ZK 
> node containing the current leader can't be found, because the ZK path has 
> changed.
> Specifically, the leader data node changed from:
> /leaders/
> to
> /leaders//leader
> It looks to me like this happened during SOLR-7844, perhaps accidentally. 
> At the least, the "Migrating to Solr 5.4" section of the README should get 
> updated with this info, since it means a rolling upgrade of a collection with 
> multiple replicas will suffer serious degradation in the number of active 
> replicas as nodes are upgraded. It's entirely possible this will reduce some 
> shards to a single active replica.



--
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-8146) Allowing SolrJ CloudSolrClient to have preferred replica for query/read

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou commented on SOLR-8146:
--

The new ticket is SOLR-8522

> Allowing SolrJ CloudSolrClient to have preferred replica for query/read
> ---
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch
>
>
> h2. Backgrouds
> Currently, the CloudSolrClient randomly picks a replica to query.
> This is done by shuffling the list of live URLs to query then, picking the 
> first item from the list.
> This ticket is to allow more flexibility and control to some extend which 
> URLs will be picked up for queries.
> Note that this is for queries only and would not affect update/delete/admin 
> operations.
> h2. Implementation
> The current patch uses regex pattern and moves to the top of the list of URLs 
> only those matching the given regex specified by the system property 
> {code}solr.preferredQueryNodePattern{code}
> Initially, I thought it may be good to have Solr nodes tagged with a string 
> pattern (snitch?) and use that pattern for matching the URLs.
> Any comment, recommendation or feedback would be appreciated.
> h2. Use Cases
> There are many cases where the ability to choose the node where queries go 
> can be very handy:
> h3. Special node for manual user queries and analytics
> One may have a SolrCLoud cluster where every node host the same set of 
> collections with:  
> - multiple large SolrCLoud nodes (L) used for production apps and 
> - have 1 small node (S) in the same cluster with less ram/cpu used only for 
> manual user queries, data export and other production issue investigation.
> This ticket would allow to configure the applications using SolrJ to query 
> only the (L) nodes
> This use case is similar to the one described in SOLR-5501 raised by [~manuel 
> lenormand]
> h3. Minimizing network traffic
>  
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 (or 
> N) separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client 
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, 
> and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no 
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever 
> possible.
> Note that write/update/delete/admin operations should not be affected.
> Note that in our use case, we have a cross DC deployment. So, replace 
> rack1/rack2 by DC1/DC2
> Any comment would be very appreciated.
> 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

[JENKINS] Lucene-Solr-Tests-5.3-Java7 - Build # 19 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.3-Java7/19/

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

Error Message:
ERROR: SolrIndexSearcher opens=28 closes=27

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=28 closes=27
at __randomizedtesting.SeedInfo.seed([490920C33720B286]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:467)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:233)
at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.cloud.SolrCloudExampleTest: 
1) Thread[id=6403, name=searcherExecutor-1589-thread-1, state=WAITING, 
group=TGRP-SolrCloudExampleTest] at sun.misc.Unsafe.park(Native Method) 
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.SolrCloudExampleTest: 
   1) Thread[id=6403, name=searcherExecutor-1589-thread-1, state=WAITING, 
group=TGRP-SolrCloudExampleTest]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([490920C33720B286]:0)


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

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=6403, 

[jira] [Updated] (SOLR-8475) Some refactoring to SolrIndexSearcher

[Shai Erera (JIRA)]

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

Shai Erera updated SOLR-8475:
-
Attachment: SOLR-8475.patch

Updated patch to latest SVN commit. Also added a note under the "5.x upgrade" 
section. I will commit it to trunk only.

> Some refactoring to SolrIndexSearcher
> -
>
> Key: SOLR-8475
> URL: https://issues.apache.org/jira/browse/SOLR-8475
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8475.patch, SOLR-8475.patch, SOLR-8475.patch, 
> SOLR-8475.patch, SOLR-8475.patch, SOLR-8475.patch, SOLR-8475.patch
>
>
> While reviewing {{SolrIndexSearcher}}, I started to correct a thing here and 
> there, and eventually it led to these changes:
> * Moving {{QueryCommand}} and {{QueryResult}} to their own classes.
> * Moving FilterImpl into a private static class (was package-private and 
> defined in the same .java file, but separate class).
> * Some code formatting, imports organizing and minor log changes.
> * Removed fieldNames (handled the TODO in the code)
> * Got rid of usage of deprecated classes such as {{LegacyNumericUtils}} and 
> {{Legacy-*-Field}}.
> I wish we'd cut down the size of this file much more (it's 2500 lines now), 
> but I've decided to stop here so that the patch is manageable. I would like 
> to explore further refactorings afterwards, e.g. extracting cache management 
> code to an outer class (but keep {{SolrIndexSearcher}}'s API the same, if 
> possible).
> If you have additional ideas of more cleanups / simplifications, I'd be glad 
> to do them.



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

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

[jira] [Updated] (SOLR-8475) Some refactoring to SolrIndexSearcher

[Shai Erera (JIRA)]

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

Shai Erera updated SOLR-8475:
-
Fix Version/s: (was: 5.5)

> Some refactoring to SolrIndexSearcher
> -
>
> Key: SOLR-8475
> URL: https://issues.apache.org/jira/browse/SOLR-8475
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-8475.patch, SOLR-8475.patch, SOLR-8475.patch, 
> SOLR-8475.patch, SOLR-8475.patch, SOLR-8475.patch, SOLR-8475.patch
>
>
> While reviewing {{SolrIndexSearcher}}, I started to correct a thing here and 
> there, and eventually it led to these changes:
> * Moving {{QueryCommand}} and {{QueryResult}} to their own classes.
> * Moving FilterImpl into a private static class (was package-private and 
> defined in the same .java file, but separate class).
> * Some code formatting, imports organizing and minor log changes.
> * Removed fieldNames (handled the TODO in the code)
> * Got rid of usage of deprecated classes such as {{LegacyNumericUtils}} and 
> {{Legacy-*-Field}}.
> I wish we'd cut down the size of this file much more (it's 2500 lines now), 
> but I've decided to stop here so that the patch is manageable. I would like 
> to explore further refactorings afterwards, e.g. extracting cache management 
> code to an outer class (but keep {{SolrIndexSearcher}}'s API the same, if 
> possible).
> If you have additional ideas of more cleanups / simplifications, I'd be glad 
> to do them.



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

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

Re: Breaking Java back-compat in Solr

[Shai Erera]

As for SOLR-8475, I will commit it to trunk only. But I think that we
should come up w/ concrete annotations in our code, and annotate classes as
we go, to back our back-compat policy. I propose that we add these:

@solr.internal - this is internal API and will change without notice. No
back-compat guarantees.
@solr.experimental - this is a candidate for a new public API, but will
likely change until it stabilizes. No (strong) back-compat guarantees.
@solr.expert - while you can use this API, we cannot guarantee strong
back-compat support. Will be on a per-case basis.
@solr.public - this is our public API, standard back-compat policy. Of
course, if something needs break, we'll discuss the case, but otherwise
users who use this API can expect to upgrade minor releases without
re-compiling their code. Immediate candidate is SolrJ.

I also propose that until we tag all classes, we treat "no annotation" as
@solr.internal (except for SolrJ code). That will force us to explicitly
tag classes that we think should at least be @solr.public, since that's the
only annotation that should draw the attention of developers.

If people agree, we can add these annotations to the build.xml, to add
proper text to javadocs.

Shai

On Sat, Jan 9, 2016 at 2:15 AM Jack Krupansky 
wrote:

> With the talk of 6.0 coming out real soon and not waiting for new work,
> will this 6.0/5.x issue become moot and morph into an issue for 7.0/6.x?
>
> Settling the criteria for Solr plugin API back-compat still seems urgent,
> but if the SOLR-8475 work can quickly get committed to trunk for 6.0 maybe
> that takes some of the pressure off. Still, I'd prefer that the back-compat
> criteria be settled ASAP.
>
>
> -- Jack Krupansky
>
> On Wed, Jan 6, 2016 at 10:43 AM, Yonik Seeley  wrote:
>
>> On Wed, Jan 6, 2016 at 1:03 AM, Anshum Gupta 
>> wrote:
>> > As I understand, seems like there's reasonable consensus that we will:
>> >
>> > 1. provide strong back-compat for for SolrJ and REST APIs
>> > 2. Strive to maintain but not guarantee *strong* back-compat for Java
>> APIs.
>>
>> I think this actually represents what our current policy already is.
>> The sticking point is perhaps "Strive to maintain" is changing
>> definition to become much more lenient, to the point of being
>> meaningless.
>>
>> Let's look at the issue that spawned this thread:
>> https://issues.apache.org/jira/browse/SOLR-8475  (Some refactoring to
>> SolrIndexSearcher)
>>
>> The issue is if QueryCommand and QueryResult should be moved out of
>> SolrIndexSearcher in 5.x (essentially a rename), or of that rename
>> should only be in 6.0.  If one's desire for a class rename (of classes
>> that are likely to be used by plugins) overrides #2, I'd argue that
>> means we essentially have no #2 at all.  Or perhaps I'm not grasping
>> why it's really that important to rename those classes.
>>
>> Regarding annotations:
>> Multiple people have suggested annotating classes that should remain
>> back compat.  If we were to do this, wouldn't we want those
>> annotations to cover the classes in question
>> (SolrIndexSearcher,QueryCommand,QueryResult)?  If not, what would they
>> cover and still be useful?
>>
>> -Yonik
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>