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

[Policeman Jenkins Server]

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

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

Error Message:
Captured an uncaught exception in thread: Thread[id=7046, 
name=testExecutor-3547-thread-10, state=RUNNABLE, 
group=TGRP-UnloadDistributedZkTest]

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


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

Error Message:
No live SolrServers available to handle this request:[http://127.0.0.1:41464, 
http://127.0.0.1:60878, http://127.0.0.1:55791, http://127.0.0.1:34595, 
http://127.0.0.1:51401]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:41464, http://127.0.0.1:60878, 
http://127.0.0.1:55791, http://127.0.0.1:34595, http://127.0.0.1:51401]
at 
__randomizedtesting.SeedInfo.seed([76F638A1B73C9AAE:FEA2077B19C0F756]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 

[jira] [Commented] (SOLR-8737) Managed synonym lists do not include the original term in the expand

[JIRA]

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

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

Committed to branch_5_5 (133b6cdb838bb1261652e469936f7aeab133e9f0) and master 
(9bb9b7900f0418517d1966cc26dc22df9c27)

> Managed synonym lists do not include the original term in the expand
> 
>
> Key: SOLR-8737
> URL: https://issues.apache.org/jira/browse/SOLR-8737
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.5
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 5.5.1
>
> Attachments: SOLR-8737.patch
>
>
> Spinoff from discussion in solr-user list 
> http://find.searchhub.org/document/8dfce8a277de0f2a
> The managed synonyms filter does not behave the same way as the original 
> synonym filter when a list is added. The original synonyms filter with 
> default {{expand=true}} produces the following map when parsing a line:
> Input:
> {noformat}
>   a, b, c
> {noformat}
> Becomes:
> {noformat}
>   a => a, b, c
>   b => a, b, c
>   c => a, b, c
> {noformat}
> But the managed filter excludes the original term in the mapping, so an input 
> {{\["a", "b", "c"\]}} becomes:
> {noformat}
>   a => b, c
>   b => a, c
>   c => a, b
> {noformat}
> This can also be seen in {{TestManagedSynonymFilterFactory.java}} where it is 
> tested explicitly, while the tests for the file based synonymfilter expect an 
> all-way expand including the original term.
> This causes a query for "a" to *not* match documents with the term "a", but 
> only those with term "b" or "c".
> The offending line in {{ManagedSynonymFilterFactory}} is this
> {code}
> 188:   treeTerms.remove(origTerm);
> {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

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

[Apache Jenkins Server]

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

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

Error Message:
Could not get expected value  'f' for path 'params/fixed' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{ 
"add":"second", "a":"A val", "fixed":"changeit", "b":"B val", 
"wt":"json"},   "context":{ "webapp":"/_x/h", "path":"/dump1", 
"httpMethod":"GET"}}

Stack Trace:
java.lang.AssertionError: Could not get expected value  'f' for path 
'params/fixed' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{
"add":"second",
"a":"A val",
"fixed":"changeit",
"b":"B val",
"wt":"json"},
  "context":{
"webapp":"/_x/h",
"path":"/dump1",
"httpMethod":"GET"}}
at 
__randomizedtesting.SeedInfo.seed([CBFF390C3BC03C13:43AB06D6953C51EB]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:458)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:247)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

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

[Policeman Jenkins Server]

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

7 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
ObjectTracker found 4 object(s) that were not released!!! 
[MockDirectoryWrapper, SolrCore, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 4 object(s) that were not 
released!!! [MockDirectoryWrapper, SolrCore, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([9BB5A7D77946914]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:238)
at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=8700, name=searcherExecutor-3740-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestLazyCores: 
   1) Thread[id=8700, name=searcherExecutor-3740-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at 

[JENKINS] Lucene-Solr-5.5-Linux (32bit/jdk1.8.0_72) - Build # 122 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/122/
Java: 32bit/jdk1.8.0_72 -server -XX:+UseG1GC

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

Error Message:
Error from server at http://127.0.0.1:45142/ybwi/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:45142/ybwi/awholynewcollection_0: non ok 
status: 500, message:Server Error
at 
__randomizedtesting.SeedInfo.seed([1AA74E5DBA90B315:92F37187146CDEED]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:511)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForNon403or404or503(AbstractFullDistribZkTestBase.java:1753)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:717)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:160)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.CollectionStateFormat2Test.test

Error Message:
No live SolrServers available to handle this request:[http://127.0.0.1:36858, 
http://127.0.0.1:49245, http://127.0.0.1:55959, http://127.0.0.1:43253, 
http://127.0.0.1:57567]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:36858, http://127.0.0.1:49245, 
http://127.0.0.1:55959, http://127.0.0.1:43253, http://127.0.0.1:57567]
at 
__randomizedtesting.SeedInfo.seed([ED8BB42D896F5A92:65DF8BF72793376A]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1547)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1808)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.testConfNameAndCollectionNameSame(CollectionStateFormat2Test.java:52)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.test(CollectionStateFormat2Test.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

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

[Apache Jenkins Server]

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

6 tests failed.
FAILED:  org.apache.solr.cloud.OverseerTest.testShardLeaderChange

Error Message:
Could not register as the leader because creating the ephemeral registration 
node in ZooKeeper failed

Stack Trace:
org.apache.solr.common.SolrException: Could not register as the leader because 
creating the ephemeral registration node in ZooKeeper failed
at 
__randomizedtesting.SeedInfo.seed([7DBFD251935D720D:A3EC55A689C587FC]:0)
at 
org.apache.solr.cloud.ShardLeaderElectionContextBase.runLeaderProcess(ElectionContext.java:212)
at 
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:173)
at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:138)
at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:310)
at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:219)
at 
org.apache.solr.cloud.OverseerTest$MockZKController.publishState(OverseerTest.java:181)
at 
org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:841)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

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

[Policeman Jenkins Server]

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

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

Error Message:
6 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=11578, 
name=pool-25-thread-1, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]   
  at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)2) Thread[id=11576, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)3) Thread[id=11574, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)4) Thread[id=11573, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:502) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)5) Thread[id=11577, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)6) Thread[id=11575, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 

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

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.CollectionStateFormat2Test.test

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:47019/gkq/xo, http://127.0.0.1:39485/gkq/xo, 
http://127.0.0.1:60685/gkq/xo, http://127.0.0.1:52863/gkq/xo, 
http://127.0.0.1:34188/gkq/xo]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:47019/gkq/xo, 
http://127.0.0.1:39485/gkq/xo, http://127.0.0.1:60685/gkq/xo, 
http://127.0.0.1:52863/gkq/xo, http://127.0.0.1:34188/gkq/xo]
at 
__randomizedtesting.SeedInfo.seed([DD94489402B7B88:858D7B53EED71670]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1547)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1808)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.testConfNameAndCollectionNameSame(CollectionStateFormat2Test.java:52)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.test(CollectionStateFormat2Test.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.CollectionStateFormat2Test.test

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:38736/a_, http://127.0.0.1:44450/a_, 
http://127.0.0.1:55606/a_, http://127.0.0.1:46572/a_, http://127.0.0.1:39910/a_]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:38736/a_, http://127.0.0.1:44450/a_, 
http://127.0.0.1:55606/a_, http://127.0.0.1:46572/a_, http://127.0.0.1:39910/a_]
at 
__randomizedtesting.SeedInfo.seed([8FC4A2FCC3CA147C:7909D266D367984]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1547)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1808)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.testConfNameAndCollectionNameSame(CollectionStateFormat2Test.java:52)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.test(CollectionStateFormat2Test.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

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

[Policeman Jenkins Server]

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

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

Error Message:
[/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_23B3A6A32FAA6E3D-001/solr-instance-015/./collection1/data,
 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_23B3A6A32FAA6E3D-001/solr-instance-015/./collection1/data/index.20160225174617965,
 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_23B3A6A32FAA6E3D-001/solr-instance-015/./collection1/data/index.20160225174617801]
 expected:<2> but was:<3>

Stack Trace:
java.lang.AssertionError: 
[/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_23B3A6A32FAA6E3D-001/solr-instance-015/./collection1/data,
 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_23B3A6A32FAA6E3D-001/solr-instance-015/./collection1/data/index.20160225174617965,
 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_23B3A6A32FAA6E3D-001/solr-instance-015/./collection1/data/index.20160225174617801]
 expected:<2> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([23B3A6A32FAA6E3D:D4C048FBE942C1DB]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:815)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1245)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

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

[Policeman Jenkins Server]

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

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

Error Message:
Could not get expected value  'CY val' for path 'response/params/y/c' full 
output: {   "responseHeader":{ "status":0, "QTime":0},   "response":{   
  "znodeVersion":0, "params":{"x":{ "a":"A val", "b":"B 
val", "":{"v":0}

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'response/params/y/c' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":0,
"params":{"x":{
"a":"A val",
"b":"B val",
"":{"v":0}
at 
__randomizedtesting.SeedInfo.seed([408E0B39E1207508:C8DA34E34FDC18F0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:458)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:165)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

An unusual (new?) multi term synonym bug?

[Ryan Josal]

I know, there's a ton of documentation about the query parser whitespace
issue, and there's also a fair bit of info on the positionLengthAttribute
issue, but I seem to have stumbled upon a new issue with multi term
synonyms: it doesn't seem to play well with a bunch of tokens in the same
position.

I have a synonym filter with this expansion:
side table,end table

I can see the synonym is applied when looking at the token stream output
for "side table".  Today I decided to throw an additional synonymFilter
immediately before that one with wordnet synonym expansions.  Wordnet
expectedly bloats the tokenstream, but all of a sudden the original end
table expansion doesn't get applied.  I see "side" followed by a bunch of
tokens in the same position, followed by a couple new tokens in the next
position, followed by "table" in the same token position, followed by some
more new tokens in the same position.  Since side is still adjacent to
table in token positions, I would expect the synonym to hit.  Is this a
known issue (what's the Jira)?  The impact seems significant.  Since
wordnet is so comprehensive, it's likely going to cause this issue with
most of my multi term synonyms.  Maybe the workaround is to apply multi
term synonyms first as best is possible, although I don't know if you have
that kind of control if all your synonyms are applied by a single
SynonymFilter.

Thanks,
Ryan

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.lucene.search.TestMinShouldMatch2.testAdvanceAllTerms

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([3A7CEF5774A32C50:AFF2F5AECFE483AB]:0)
at 
org.apache.lucene.search.BooleanScorer.scoreWindowIntoBitSetAndReplay(BooleanScorer.java:218)
at 
org.apache.lucene.search.BooleanScorer.scoreWindowMultipleScorers(BooleanScorer.java:266)
at 
org.apache.lucene.search.BooleanScorer.scoreWindow(BooleanScorer.java:311)
at org.apache.lucene.search.BooleanScorer.score(BooleanScorer.java:335)
at 
org.apache.lucene.search.BulkScorerWrapperScorer.refill(BulkScorerWrapperScorer.java:52)
at 
org.apache.lucene.search.BulkScorerWrapperScorer.access$500(BulkScorerWrapperScorer.java:25)
at 
org.apache.lucene.search.BulkScorerWrapperScorer$2.advance(BulkScorerWrapperScorer.java:101)
at 
org.apache.lucene.search.TestMinShouldMatch2.assertAdvance(TestMinShouldMatch2.java:176)
at 
org.apache.lucene.search.TestMinShouldMatch2.testAdvanceAllTerms(TestMinShouldMatch2.java:257)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:804)




Build Log:
[...truncated 

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

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: Could not get expected value  'first' for path 
'response/params/x/_appends_/add' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":3,
"params":{
  "x":{
"a":"A val",
"b":"B val",
"":{"v":0}},
  "y":{
"p":"P val",
"q":"Q val",
"":{"v":2}
at 
__randomizedtesting.SeedInfo.seed([454F0CFC64E400D8:CD1B3326CA186D20]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:458)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:236)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

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

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.CollectionStateFormat2Test.test

Error Message:
No live SolrServers available to handle this request:[http://127.0.0.1:39485, 
http://127.0.0.1:48255, http://127.0.0.1:58198, http://127.0.0.1:34808, 
http://127.0.0.1:54537]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:39485, http://127.0.0.1:48255, 
http://127.0.0.1:58198, http://127.0.0.1:34808, http://127.0.0.1:54537]
at 
__randomizedtesting.SeedInfo.seed([CB4EDA80DFAE153F:431AE55A715278C7]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1547)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1808)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.testConfNameAndCollectionNameSame(CollectionStateFormat2Test.java:52)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.test(CollectionStateFormat2Test.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Updated] (SOLR-8738) invalid DBQ initially sent to a non-leader node will report success

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-8738:
---
Attachment: SOLR-8738.patch

here's a MiniSolrCloudCluster based test patch i hacked out of the existing 
SOLR-445 work demonstrating the problem.

still tracing trough to try and figure out why the errors aren't getting 
propogated.

> invalid DBQ initially sent to a non-leader node will report success
> ---
>
> Key: SOLR-8738
> URL: https://issues.apache.org/jira/browse/SOLR-8738
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8738.patch
>
>
> Discovered this while working on SOLR-445.
> If a Delete By Query gets sent to a node which is not hosting a leader (ie: 
> only hosts replicas, or doesn't host any cores related to the specified 
> collection) then a success will be returned, even if the DBQ is completely 
> malformed and actually failed.



--
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-5743) Faceting with BlockJoin support

[Vijay Sekhri (JIRA)]

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

Vijay Sekhri commented on SOLR-5743:


Mikhail, 
For issues like these and some others should I open a separate Jira  for 
manageability ?  I also observed that facet.prefix is not being honored on 
child.facet.field . Let me know and I can open a Jira .
Thanks 


> Faceting with BlockJoin support
> ---
>
> Key: SOLR-5743
> URL: https://issues.apache.org/jira/browse/SOLR-5743
> Project: Solr
>  Issue Type: New Feature
>  Components: faceting
>Reporter: abipc
>Assignee: Mikhail Khludnev
>  Labels: features
> Fix For: 5.5, master
>
> Attachments: SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> cluster.jpg, service_baseline.png, service_new_baseline.jpg, 
> solr_baseline.jpg, solr_new_baseline.jpg
>
>
> For a sample inventory(note - nested documents) like this -   
>  
> 10
> parent
> Nike
> 
> 11
> Red
> XL
> 
> 
> 12
> Blue
> XL
> 
> 
> Faceting results must contain - 
> Red(1)
> XL(1) 
> Blue(1) 
> for a "q=*" query. 
> PS : The inventory example has been taken from this blog - 
> http://blog.griddynamics.com/2013/09/solr-block-join-support.html



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

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

[jira] [Commented] (LUCENE-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Mike Drob (JIRA)]

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

Mike Drob commented on LUCENE-6993:
---

Steve, did you get a chance to look at the buffer adjustment? I'm going to 
pre-emptively remove the hack from our code and trust that it will be in the 
next release of JFlex.

Unrelated; the ClassicTokenizer is already advertised as a legacy option -- I 
don't think it makes sense to create a new version of it here. WDYT?

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



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

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

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.CollectionStateFormat2Test.test

Error Message:
No live SolrServers available to handle this request:[http://127.0.0.1:50297, 
http://127.0.0.1:32937, http://127.0.0.1:59302, http://127.0.0.1:44651, 
http://127.0.0.1:38975]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:50297, http://127.0.0.1:32937, 
http://127.0.0.1:59302, http://127.0.0.1:44651, http://127.0.0.1:38975]
at 
__randomizedtesting.SeedInfo.seed([112B8D3F58D984D7:997FB2E5F625E92F]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1547)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1808)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.testConfNameAndCollectionNameSame(CollectionStateFormat2Test.java:52)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.test(CollectionStateFormat2Test.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

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

[Policeman Jenkins Server]

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

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

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.DistribJoinFromCollectionTest: 1) Thread[id=15674, 
name=qtp1056385281-15674-selector-ServerConnectorManager@6ab399f1/0, 
state=RUNNABLE, group=TGRP-DistribJoinFromCollectionTest] at 
sun.nio.ch.DevPollArrayWrapper.poll0(Native Method) at 
sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223) at 
sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:98) at 
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:600)
 at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:549)
 at 
org.eclipse.jetty.util.thread.NonBlockingThread.run(NonBlockingThread.java:52)  
   at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) 
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.DistribJoinFromCollectionTest: 
   1) Thread[id=15674, 
name=qtp1056385281-15674-selector-ServerConnectorManager@6ab399f1/0, 
state=RUNNABLE, group=TGRP-DistribJoinFromCollectionTest]
at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method)
at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223)
at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:98)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:600)
at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:549)
at 
org.eclipse.jetty.util.thread.NonBlockingThread.run(NonBlockingThread.java:52)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([AB3B7BF833D9F3C3]:0)


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

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=15674, 
name=qtp1056385281-15674-selector-ServerConnectorManager@6ab399f1/0, 
state=RUNNABLE, group=TGRP-DistribJoinFromCollectionTest] at 
sun.nio.ch.DevPollArrayWrapper.poll0(Native Method) at 
sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223) at 
sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:98) at 
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:600)
 at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:549)
 at 
org.eclipse.jetty.util.thread.NonBlockingThread.run(NonBlockingThread.java:52)  
   at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=15674, 
name=qtp1056385281-15674-selector-ServerConnectorManager@6ab399f1/0, 
state=RUNNABLE, group=TGRP-DistribJoinFromCollectionTest]
at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method)
at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223)
at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:98)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:600)
at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:549)
at 

[jira] [Commented] (SOLR-8738) invalid DBQ initially sent to a non-leader node will report success

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8738:


The most trivial/obvious way to reproduce is...

* {{bin/solr -e cloud}}
* Pick "*3*" for number of nodes
* accept the default port numbers (8983, 7574, 8984)
* accept the default collection name (gettingstarted)
* pick "*1*" for the number of shards
* accept the default number of replicas per shard (2)
* accept the default config set (data_driven_schema_configs)

(So now you should have a single collection with a single shard with 2 replicas 
on 2 diff nodes and the remaining node doesn't host any cores related to the 
collection)

Now try running a broken DBQ against all 3 nodes...

{noformat}
$ curl -H 'Content-Type: application/json' 
'http://127.0.1.1:8983/solr/gettingstarted/update' --data-binary 
'{"delete":{"query" : "foo_i:yak"}}'
{"responseHeader":{"status":400,"QTime":18},"error":{"metadata":["error-class","org.apache.solr.common.SolrException","root-error-class","org.apache.solr.common.SolrException"],"msg":"Invalid
 Number: yak","code":400}}
$ curl -H 'Content-Type: application/json' 
'http://127.0.1.1:8984/solr/gettingstarted/update' --data-binary 
'{"delete":{"query" : "foo_i:yak"}}'
{"responseHeader":{"status":0,"QTime":25}}
$ curl -H 'Content-Type: application/json' 
'http://127.0.1.1:7574/solr/gettingstarted/update' --data-binary 
'{"delete":{"query" : "foo_i:yak"}}'
{"responseHeader":{"status":0,"QTime":7}}
{noformat}

...only the node hosting the leader correctly repsponds back with the error, 
requests that initially hit nodes only hosting replicas or not hosting any 
cores incorrectly indicate that the delete succeeded.



2 important notes:

# This can also be reproduced using {{numShards > 1}}, most easily by running 
{{-e cloud}} and choosing *4* nodes, and accepting the default 2 shards, 2 
replicas.  Then repeat the same curl commands above over all 4 ports.
#* you should see 2 nodes correctly return failures, and 2 nodes incorrectly 
claim success
# You can also reproduce using {{-e cloud -noprompt}} but since that that 
defaults to only 2 nodes they are garunteed to each have a leader on them, so 
you have to be more explicit about the requests.
#* Use the Solr UI to determine the _non-leader_ core_node_names (ex: 
{{gettingstarted_shard1_replica1}}) and which node they are located on, then 
use those in url instead of the simple collection name (otherwise smple 
collection paths will be auto-route to a leader on each node)




> invalid DBQ initially sent to a non-leader node will report success
> ---
>
> Key: SOLR-8738
> URL: https://issues.apache.org/jira/browse/SOLR-8738
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> Discovered this while working on SOLR-445.
> If a Delete By Query gets sent to a node which is not hosting a leader (ie: 
> only hosts replicas, or doesn't host any cores related to the specified 
> collection) then a success will be returned, even if the DBQ is completely 
> malformed and actually failed.



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

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

[jira] [Created] (SOLR-8738) invalid DBQ initially sent to a non-leader node will report success

[Hoss Man (JIRA)]

Hoss Man created SOLR-8738:
--

 Summary: invalid DBQ initially sent to a non-leader node will 
report success
 Key: SOLR-8738
 URL: https://issues.apache.org/jira/browse/SOLR-8738
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man


Discovered this while working on SOLR-445.

If a Delete By Query gets sent to a node which is not hosting a leader (ie: 
only hosts replicas, or doesn't host any cores related to the specified 
collection) then a success will be returned, even if the DBQ is completely 
malformed and actually failed.




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

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

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

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.CollectionStateFormat2Test.test

Error Message:
No live SolrServers available to handle this request:[https://127.0.0.1:58580, 
https://127.0.0.1:58209, https://127.0.0.1:48127, https://127.0.0.1:38258, 
https://127.0.0.1:51816]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[https://127.0.0.1:58580, https://127.0.0.1:58209, 
https://127.0.0.1:48127, https://127.0.0.1:38258, https://127.0.0.1:51816]
at 
__randomizedtesting.SeedInfo.seed([4BB98A44D71E4EB1:C3EDB59E79E22349]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1547)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1808)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.testConfNameAndCollectionNameSame(CollectionStateFormat2Test.java:52)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.test(CollectionStateFormat2Test.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.CollectionStateFormat2Test.test

Error Message:
No live SolrServers available to handle this 
request:[https://127.0.0.1:37248/l_w/l, https://127.0.0.1:38257/l_w/l, 
https://127.0.0.1:55012/l_w/l, https://127.0.0.1:37796/l_w/l, 
https://127.0.0.1:61162/l_w/l]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[https://127.0.0.1:37248/l_w/l, 
https://127.0.0.1:38257/l_w/l, https://127.0.0.1:55012/l_w/l, 
https://127.0.0.1:37796/l_w/l, https://127.0.0.1:61162/l_w/l]
at 
__randomizedtesting.SeedInfo.seed([6AD28877BCD23210:E286B7AD122E5FE8]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1547)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1808)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.testConfNameAndCollectionNameSame(CollectionStateFormat2Test.java:52)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.test(CollectionStateFormat2Test.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Commented] (SOLR-4900) Leader election deadlock after restarting leader in 4.2.1

[Frank J Kelly (JIRA)]

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

Frank J Kelly commented on SOLR-4900:
-

Hit this also. Now we just stop the service first, and wait for a leader 
election before restart.

Surely there is some way to resolve this "easily"?
If Solr says it is not the leader, ZK should elect a new leader?

> Leader election deadlock after restarting leader in 4.2.1
> -
>
> Key: SOLR-4900
> URL: https://issues.apache.org/jira/browse/SOLR-4900
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.2
> Environment: Linux 64 bit, Tomcat 6.0.35, Java 6u27 64 bit
>Reporter: John Guerrero
>Assignee: Mark Miller
>
> Copying post from 
> http://lucene.472066.n3.nabble.com/Leader-election-deadlock-after-restarting-leader-in-4-2-1-td4067988.html
> SOLR 4.2.1, tomcat 6.0.35, CentOS 6.2 (2.6.32-220.4.1.el6.x86_64 #1 SMP), 
> java 6u27 64 bit 
> 6 nodes, 2 shards, 3 replicas each.  Names changed to r1s2 (replica1 - shard 
> 2), r2s2, and r3s2 for each replica in shard 2. 
> *What we see*:
> * Under production load, we restart a leader (r1s2), and observe in the cloud 
> admin 
> that the old leader is in state "Down" and no new leader is ever elected. 
> * The system will stay like this until we stop the old leader (or cause a ZK 
> timeout...see below). 
> *Please note*: the leader is killed, then kill -9'd 5 seconds later, before 
> restarting.  We have since changed this. 
> *Digging into the logs on the old leader (r1s2 = replica1-shard 2)*:
> * The old leader restarted at 5:23:29 PM, but appears to be stuck in 
> SolrDispatchFilter.init() -- (See recovery at bottom). 
> * It doesn't want to become leader, possibly due to the unclean shutdown. 
> May 28, 2013 5:24:42 PM org.apache.solr.update.PeerSync handleVersions 
> INFO: PeerSync: core=browse url=http://r1s2:8080/solr  Our versions are too 
> old. ourHighThreshold=1436325665147191297 
> otherLowThreshold=1436325775374548992 
> * It then tries to recover, but cannot, because there is no leader. 
> May 28, 2013 5:24:43 PM org.apache.solr.common.SolrException log 
> SEVERE: Error while trying to recover. 
> core=browse:org.apache.solr.common.SolrException: No registered leader was 
> found, collection:browse slice:shard2 
> * Meanwhile, it appears that blocking in init(), prevents the http-8080 
> handler from starting (See recovery at bottom). 
> *Digging into the other replicas (r2s2)*:
> * For some reason, the old leader (r1s2) remains in the list of replicas that 
> r2s2 attempts to sync to. 
> May 28, 2013 5:23:42 PM org.apache.solr.update.PeerSync sync 
> INFO: PeerSync: core=browse url=http://r2s2:8080/solr START 
> replicas=[http://r1s2:8080/solr/browse/, http://r3s2:8080/solr/browse/] 
> nUpdates=100 
> * This apparently fails (30 second timeout), possibly due to http-8080 
> handler not being started on r1s2. 
> May 28, 2013 5:24:12 PM org.apache.solr.update.PeerSync handleResponse 
> WARNING: PeerSync: core=browse url=http://r2s2:8080/solr  exception talking 
> to http://r1s2:8080/solr/browse/, failed 
> org.apache.solr.client.solrj.SolrServerException: Timeout occured while 
> waiting response from server at: http://r1s2:8080/solr/browse
> *At this point, the cluster will remain indefinitely without a leader, if 
> nothing else changes.*
> But in this particular instance, we took some stack and heap dumps from r1s2, 
> which paused java 
> long enough to cause a *zookeeper timeout on the old leader (r1s2)*: 
> May 28, 2013 5:33:26 PM org.apache.zookeeper.ClientCnxn$SendThread run 
> INFO: Client session timed out, have not heard from server in 38226ms for 
> sessionid 0x23d28e0f584005d, closing socket connection and attempting 
> reconnect 
> Then, one of the replicas (r3s2) finally stopped trying to sync to r1s2 and 
> succeeded in becoming leader: 
> May 28, 2013 5:33:34 PM org.apache.solr.update.PeerSync sync 
> INFO: PeerSync: core=browse url=http://r3s2:8080/solr START 
> replicas=[http://r2s2:8080/solr/browse/] nUpdates=100 
> May 28, 2013 5:33:34 PM org.apache.solr.update.PeerSync handleVersions 
> INFO: PeerSync: core=browse url=http://r3s2:8080/solr  Received 100 versions 
> from r2s2:8080/solr/browse/ 
> May 28, 2013 5:33:34 PM org.apache.solr.update.PeerSync handleVersions 
> INFO: PeerSync: core=browse url=http://r3s2:8080/solr  Our versions are 
> newer. ourLowThreshold=1436325775374548992 otherHigh=1436325775805513730 
> May 28, 2013 5:33:34 PM org.apache.solr.update.PeerSync sync 
> INFO: PeerSync: core=browse url=http://r3s2:8080/solr DONE. sync succeeded 
> Now that we have a leader, r1s2 can succeed in recovery and finish 
> SolrDispatchFilter.init(), 
> apparently allowing the http-8080 handler to start (r1s2). 
> May 

[jira] [Resolved] (LUCENE-6541) Geo3d WGS84 parameters not quite right

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-6541.

   Resolution: Fixed
Fix Version/s: 5.4
   6.0
   master

Looks like this patch was already applied at some point.

> Geo3d WGS84 parameters not quite right
> --
>
> Key: LUCENE-6541
> URL: https://issues.apache.org/jira/browse/LUCENE-6541
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Karl Wright
> Fix For: master, 6.0, 5.4
>
> Attachments: LUCENE-6541.patch
>
>
> The PlanetModel parameters for WGS84 are correct only to within 7 significant 
> digits.  In particular, the polar radius is not quite the WGS84 value.



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

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

[jira] [Resolved] (LUCENE-7048) Add XXXPoint.newSetQuery to match a set of points

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-7048.

Resolution: Fixed

> Add XXXPoint.newSetQuery to match a set of points
> -
>
> Key: LUCENE-7048
> URL: https://issues.apache.org/jira/browse/LUCENE-7048
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master, 6.0
>
> Attachments: LUCENE-7048.patch, LUCENE-7048.patch
>
>
> This is the analog of {{TermsQuery}} for dimensional points, to (relatively) 
> efficiently match any docs whose point value is in the specified set.



--
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-7048) Add XXXPoint.newSetQuery to match a set of points

[ASF subversion and git services (JIRA)]

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

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

Commit b9d46e4fd6de73524be7bb4be0b35c066fed4fae in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b9d46e4 ]

LUCENE-7048: add changes entry


> Add XXXPoint.newSetQuery to match a set of points
> -
>
> Key: LUCENE-7048
> URL: https://issues.apache.org/jira/browse/LUCENE-7048
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master, 6.0
>
> Attachments: LUCENE-7048.patch, LUCENE-7048.patch
>
>
> This is the analog of {{TermsQuery}} for dimensional points, to (relatively) 
> efficiently match any docs whose point value is in the specified set.



--
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-7048) Add XXXPoint.newSetQuery to match a set of points

[ASF subversion and git services (JIRA)]

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

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

Commit 446ce8604e4baff4f4e486e39f7e885f0d8d0c57 in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=446ce86 ]

LUCENE-7048: add XXXPoint.newSetQuery to match documents with any values from 
the specified set (this is the analog of TermsQuery, for points)

Merge branch 'point_set_query'


> Add XXXPoint.newSetQuery to match a set of points
> -
>
> Key: LUCENE-7048
> URL: https://issues.apache.org/jira/browse/LUCENE-7048
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master, 6.0
>
> Attachments: LUCENE-7048.patch, LUCENE-7048.patch
>
>
> This is the analog of {{TermsQuery}} for dimensional points, to (relatively) 
> efficiently match any docs whose point value is in the specified set.



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

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

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.CollectionStateFormat2Test.test

Error Message:
No live SolrServers available to handle this 
request:[https://127.0.0.1:41537/o_hv/b, https://127.0.0.1:48351/o_hv/b, 
https://127.0.0.1:43266/o_hv/b, https://127.0.0.1:39788/o_hv/b, 
https://127.0.0.1:59217/o_hv/b]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[https://127.0.0.1:41537/o_hv/b, 
https://127.0.0.1:48351/o_hv/b, https://127.0.0.1:43266/o_hv/b, 
https://127.0.0.1:39788/o_hv/b, https://127.0.0.1:59217/o_hv/b]
at 
__randomizedtesting.SeedInfo.seed([F2F93C98407676F3:7AAD0342EE8A1B0B]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1547)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1808)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.testConfNameAndCollectionNameSame(CollectionStateFormat2Test.java:52)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.test(CollectionStateFormat2Test.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Commented] (LUCENE-7048) Add XXXPoint.newSetQuery to match a set of points

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7048:
-

still looks good. thanks Mike.

> Add XXXPoint.newSetQuery to match a set of points
> -
>
> Key: LUCENE-7048
> URL: https://issues.apache.org/jira/browse/LUCENE-7048
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master, 6.0
>
> Attachments: LUCENE-7048.patch, LUCENE-7048.patch
>
>
> This is the analog of {{TermsQuery}} for dimensional points, to (relatively) 
> efficiently match any docs whose point value is in the specified set.



--
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-8737) Managed synonym lists do not include the original term in the expand

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-8737:
--

Thanks for fixing [~janhoy]. As a work-around until this is released, users can 
send in the mappings as a map, i.e.

{code}
curl -v -X PUT \
  -H 'Content-type:application/json' \
  --data-binary '{ "a": ["a","b","c"], "b": ["a","b","c"], "c":["a","b","c"]}' \
  'http://localhost:8983/solr/techproducts/schema/analysis/synonyms/english'
{code}

> Managed synonym lists do not include the original term in the expand
> 
>
> Key: SOLR-8737
> URL: https://issues.apache.org/jira/browse/SOLR-8737
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.5
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 5.5.1
>
> Attachments: SOLR-8737.patch
>
>
> Spinoff from discussion in solr-user list 
> http://find.searchhub.org/document/8dfce8a277de0f2a
> The managed synonyms filter does not behave the same way as the original 
> synonym filter when a list is added. The original synonyms filter with 
> default {{expand=true}} produces the following map when parsing a line:
> Input:
> {noformat}
>   a, b, c
> {noformat}
> Becomes:
> {noformat}
>   a => a, b, c
>   b => a, b, c
>   c => a, b, c
> {noformat}
> But the managed filter excludes the original term in the mapping, so an input 
> {{\["a", "b", "c"\]}} becomes:
> {noformat}
>   a => b, c
>   b => a, c
>   c => a, b
> {noformat}
> This can also be seen in {{TestManagedSynonymFilterFactory.java}} where it is 
> tested explicitly, while the tests for the file based synonymfilter expect an 
> all-way expand including the original term.
> This causes a query for "a" to *not* match documents with the term "a", but 
> only those with term "b" or "c".
> The offending line in {{ManagedSynonymFilterFactory}} is this
> {code}
> 188:   treeTerms.remove(origTerm);
> {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

Re: Zookeeper and Solr Clients

[Scott Blum]

You probably also want a child watch on live_nodes to monitor connected
nodes.

On Thu, Feb 25, 2016 at 11:12 AM, Upayavira  wrote:

> I've recently had a patch merged into Pysolr that adds ZK awareness
> (compatible with custerstate.json). Now I need to update it to be
> compatible with the newer state.json, and I just wanted to confirm my
> understanding
>
> If we create a Python 'client' that is tied to a specific collection,
> then all I need to do is set up a watch on
> /collections/${collection}/state.json, and update the list of nodes
> accordingly (as I would have on a watch on clusterstate.json) when
> state.json changes.
>
> There's a lot more that *could* be done, but for the basics, it seems
> that's enough.
>
> Is it really this simple?
>
> Upayavira
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Resolved] (SOLR-8420) Date statistics: sumOfSquares overflows long

[JIRA]

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

Tomás Fernández Löbbe resolved SOLR-8420.
-
   Resolution: Fixed
Fix Version/s: master

> Date statistics: sumOfSquares overflows long
> 
>
> Key: SOLR-8420
> URL: https://issues.apache.org/jira/browse/SOLR-8420
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 5.4
>Reporter: Tom Hill
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Fix For: master
>
> Attachments: 0001-Fix-overflow-in-date-statistics.patch, 
> 0001-Fix-overflow-in-date-statistics.patch, 
> 0001-Fix-overflow-in-date-statistics.patch, SOLR-8420.patch, StdDev.java
>
>
> The values for Dates are large enough that squaring them overflows a "long" 
> field. This should be converted to a double. 
> StatsValuesFactory.java, line 755 DateStatsValues#updateTypeSpecificStats Add 
> a cast to double 
> sumOfSquares += ( (double)value * value * count);



--
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-8722) Don't force a full ZkStateReader refresh on every Overseer operation

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8722:
--

No problem!  Welcome back, hope you had a good trip.

What would you suggest in this case?  Spinning for a very long time when the 
remote call might have failed quickly seems bad.  What other handler methods do 
you think demonstrate the correct pattern?  The code can be hard to follow.  
Sometime when you're on IRC I'd love to pick your brain about the code in 
OverseerCollectionMessageHandler & OverseerTaskProcessor.

> Don't force a full ZkStateReader refresh on every Overseer operation
> 
>
> Key: SOLR-8722
> URL: https://issues.apache.org/jira/browse/SOLR-8722
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud
> Attachments: SOLR-8722.patch
>
>
> We're doing an unnecessary ZkStateReader forced refresh on all Overseer 
> operations.  This isn't necessary because ZkStateReader keeps itself up to 
> date.
> According to [~shalinmangar]'s analysis, we just need to put a wait loop at 
> the end of addReplica to observe the state change.



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

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

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

[JIRA]

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

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

Assignee: Tomás Fernández Löbbe

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



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

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

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

[Policeman Jenkins Server]

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

7 tests failed.
FAILED:  org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([D86F76B8CD5B898B:3135CD8053C21923]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:764)
at 
org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir(TestArbitraryIndexDir.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=*[count(//doc)=1]
xml response was: 

00


request was:q=id:2=standard=0=20=2.2
at 

Zookeeper and Solr Clients

[Upayavira]

I've recently had a patch merged into Pysolr that adds ZK awareness
(compatible with custerstate.json). Now I need to update it to be
compatible with the newer state.json, and I just wanted to confirm my
understanding

If we create a Python 'client' that is tied to a specific collection,
then all I need to do is set up a watch on
/collections/${collection}/state.json, and update the list of nodes
accordingly (as I would have on a watch on clusterstate.json) when
state.json changes.

There's a lot more that *could* be done, but for the basics, it seems
that's enough.

Is it really this simple?

Upayavira

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

[jira] [Updated] (SOLR-7341) xjoin - join data from external sources

[Tom Winch (JIRA)]

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

Tom Winch updated SOLR-7341:

Fix Version/s: (was: 5.3.1)
   5.3.2

> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Tom Winch
>Priority: Minor
> Fix For: 4.10.3, 5.3.2, master
>
> Attachments: SOLR-7341.patch-4.10.3, SOLR-7341.patch-4_10, 
> SOLR-7341.patch-5.3.2, SOLR-7341.patch-5_3, SOLR-7341.patch-master, 
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR 
> results in a query and the SOLR result set to be filtered by the results of 
> an external query. Values from the external results are made available in the 
> SOLR results and may also be used to boost the scores of corresponding 
> documents during the search. The contrib consists of the Java classes 
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and 
> associated classes), which must be configured in solrconfig.xml, and the 
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the 
> user to provide the link between SOLR and the external results source (but 
> see below for details of how to use the in-built SimpleXJoinResultsFactory 
> implementation). External results and SOLR documents are matched via a single 
> configurable attribute (the "join field").
> To include the XJoin contrib classes, add the following config to 
> solrconfig.xml:
> {code:xml}
> 
>   ..
>
>regex=".*\.jar" />
>regex="solr-xjoin-\d.*\.jar" />
>   ..
> 
> {code}
> Note that any JARs containing implementations of the XJoinResultsFactory must 
> also be included.
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an 
> external source to perform a query (or otherwise collect results). Parameters 
> with prefix ".external." are passed from the SOLR query URL 
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and 
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR 
> search to generate external results, and is passed parameters from the SOLR 
> query URL (as above)
> For example, the implementation might perform queries of an external source 
> based on the 'q' SOLR query URL parameter (in full,  name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults() 
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result 
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending) 
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component, 
> configured in solrconfig.xml and included in one or more SOLR request 
> handlers. There is one XJoin search component per external source, and each 
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves 
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and 
> external results via the join field, adding attributes from the external 
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing 
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR 
> documents and external results
> * external - this parameter set is passed to configure the 
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
>  class="org.apache.solr.search.xjoin.XJoinSearchComponent">
>   test.TestXJoinResultsFactory
>   id
>   
> 1,2,3
>   
> 
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during 
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure 
> it. To properly use the XJoinSearchComponent in a request handler, it must be 
> included at the start and end of the component list, and may be configured 
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults 
> implementation (created by the factory at search time) to be 

[jira] [Updated] (SOLR-7341) xjoin - join data from external sources

[Tom Winch (JIRA)]

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

Tom Winch updated SOLR-7341:

Attachment: SOLR-7341.patch-master
SOLR-7341.patch-5.3.2
SOLR-7341.patch-4.10.3

Git patches for 4.10.3, 5.3.2 and master that include the 
SimpleXJoinResultsFactory

> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Tom Winch
>Priority: Minor
> Fix For: 4.10.3, 5.3.1, master
>
> Attachments: SOLR-7341.patch-4.10.3, SOLR-7341.patch-4_10, 
> SOLR-7341.patch-5.3.2, SOLR-7341.patch-5_3, SOLR-7341.patch-master, 
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR 
> results in a query and the SOLR result set to be filtered by the results of 
> an external query. Values from the external results are made available in the 
> SOLR results and may also be used to boost the scores of corresponding 
> documents during the search. The contrib consists of the Java classes 
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and 
> associated classes), which must be configured in solrconfig.xml, and the 
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the 
> user to provide the link between SOLR and the external results source (but 
> see below for details of how to use the in-built SimpleXJoinResultsFactory 
> implementation). External results and SOLR documents are matched via a single 
> configurable attribute (the "join field").
> To include the XJoin contrib classes, add the following config to 
> solrconfig.xml:
> {code:xml}
> 
>   ..
>
>regex=".*\.jar" />
>regex="solr-xjoin-\d.*\.jar" />
>   ..
> 
> {code}
> Note that any JARs containing implementations of the XJoinResultsFactory must 
> also be included.
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an 
> external source to perform a query (or otherwise collect results). Parameters 
> with prefix ".external." are passed from the SOLR query URL 
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and 
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR 
> search to generate external results, and is passed parameters from the SOLR 
> query URL (as above)
> For example, the implementation might perform queries of an external source 
> based on the 'q' SOLR query URL parameter (in full,  name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults() 
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result 
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending) 
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component, 
> configured in solrconfig.xml and included in one or more SOLR request 
> handlers. There is one XJoin search component per external source, and each 
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves 
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and 
> external results via the join field, adding attributes from the external 
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing 
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR 
> documents and external results
> * external - this parameter set is passed to configure the 
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
>  class="org.apache.solr.search.xjoin.XJoinSearchComponent">
>   test.TestXJoinResultsFactory
>   id
>   
> 1,2,3
>   
> 
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during 
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure 
> it. To properly use the XJoinSearchComponent in a request handler, it must be 
> included at the start and end of the component list, and may be configured 
> with the following query parameters:

[jira] [Updated] (SOLR-7341) xjoin - join data from external sources

[Tom Winch (JIRA)]

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

Tom Winch updated SOLR-7341:

Description: 
h2. XJoin

The "xjoin" SOLR contrib allows external results to be joined with SOLR results 
in a query and the SOLR result set to be filtered by the results of an external 
query. Values from the external results are made available in the SOLR results 
and may also be used to boost the scores of corresponding documents during the 
search. The contrib consists of the Java classes XJoinSearchComponent, 
XJoinValueSourceParser and XJoinQParserPlugin (and associated classes), which 
must be configured in solrconfig.xml, and the interfaces XJoinResultsFactory 
and XJoinResults, which are implemented by the user to provide the link between 
SOLR and the external results source (but see below for details of how to use 
the in-built SimpleXJoinResultsFactory implementation). External results and 
SOLR documents are matched via a single configurable attribute (the "join 
field").

To include the XJoin contrib classes, add the following config to 
solrconfig.xml:

{code:xml}

  ..
   
  
  
  ..

{code}

Note that any JARs containing implementations of the XJoinResultsFactory must 
also be included.

h2. Java classes and interfaces

h3. XJoinResultsFactory

The user implementation of this interface is responsible for connecting to an 
external source to perform a query (or otherwise collect results). Parameters 
with prefix ".external." are passed from the SOLR query URL to 
pararameterise the search. The interface has the following methods:

* void init(NamedList args) - this is called during SOLR initialisation, and 
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR 
search to generate external results, and is passed parameters from the SOLR 
query URL (as above)

For example, the implementation might perform queries of an external source 
based on the 'q' SOLR query URL parameter (in full, .external.q).

h3. XJoinResults
A user implementation of this interface is returned by the getResults() method 
of the XJoinResultsFactory implementation. It has methods:

* Object getResult(String joinId) - this should return a particular result 
given the value of the join attribute
* Iterable getJoinIds() - this should return an ordered (ascending) 
list of the join attribute values for all results of the external search

h3. XJoinSearchComponent

This is the central Java class of the contrib. It is a SOLR search component, 
configured in solrconfig.xml and included in one or more SOLR request handlers. 
There is one XJoin search component per external source, and each has two main 
responsibilities:

* Before the SOLR search, it connects to the external source and retrieves 
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and 
external results via the join field, adding attributes from the external 
results to documents in the SOLR results set

It takes the following initialisation parameters:

* factoryClass - this specifies the user-supplied class implementing 
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR 
documents and external results
* external - this parameter set is passed to configure the XJoinResultsFactory 
implementation

For example, in solrconfig.xml:

{code:xml}

  test.TestXJoinResultsFactory
  id
  
1,2,3
  

{code}

Here, the search component instantiates a new TextXJoinResultsFactory during 
initialisation, and passes it the "values" parameter (1, 2, 3) to configure it. 
To properly use the XJoinSearchComponent in a request handler, it must be 
included at the start and end of the component list, and may be configured with 
the following query parameters:

* results - a comma-separated list of attributes from the XJoinResults 
implementation (created by the factory at search time) to be included in the 
SOLR results
* fl - a comma-separated list of attributes from results objects (contained in 
an XJoinResults implementation) to be included in the SOLR results

For example:
{code:xml}

  
..
true
xx
test_count
id,value
  
  
xjoin_test
  
  
xjoin_test
  

{code}

Note that, to include the list of join ids returned by the external source in 
the SOLR results (likely for debug purposes), the value 'join_ids' may be 
specified in the "results" parameter.

h3. XJoinQParserPlugin

This query parser plugin constructs a query from the results of the external 
searches, and is based on the TermsQParserPlugin. It takes the following local 
parameters:

* method - as the TermsQParserPlugin, this specifies how to build the Lucene 
query based on the join ids contained in external results; one of termsFilter, 
booleanQuery, automaton, 

[jira] [Commented] (SOLR-8734) fix deprecation warnings for absent (maxMergeDocs|mergeFactor)

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-8734:
-

Hello these configurations have neither  nor  
configurated.


> fix deprecation warnings for absent (maxMergeDocs|mergeFactor)
> --
>
> Key: SOLR-8734
> URL: https://issues.apache.org/jira/browse/SOLR-8734
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, master
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8734.patch, SOLR-8734.patch
>
>
> [~markus17] wrote on the solr-user mailing list:
> bq. 5.5.0 SOLR-8621 deprecation warnings without maxMergeDocs or mergeFactor
> ...
> bq. o.a.s.c.Config Beginning with Solr 5.5,  is deprecated, 
> configure it on the relevant  instead.
> ...
> bq. On my development machine for all cores. None of the cores has either 
> parameter configured. Is this expected?
> ...
> [~cpoerschke] replied:
> ...
> bq. Could you advise if/that the solrconfig.xml has a  element 
> (for which deprecated warnings would appear separately) or that the 
> solrconfig.xml has no  element?
> ...
> bq. If either is the case then yes based on the code 
> (SolrIndexConfig.java#L153) the warnings would be expected-and-harmless 
> though admittedly are confusing, and fixable.
> ...



--
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-8349) Allow sharing of large in memory data structures across cores

[Gus Heck (JIRA)]

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

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

Patch with support for multiple decodings of the same blob

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



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
timed out waiting for collection1 startAt time to exceed: Fri Feb 26 00:00:35 
JST 2016

Stack Trace:
java.lang.AssertionError: timed out waiting for collection1 startAt time to 
exceed: Fri Feb 26 00:00:35 JST 2016
at 
__randomizedtesting.SeedInfo.seed([94718D40A64E9A54:4FDA8D86A366F3E7]: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:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:804)




Build Log:
[...truncated 11154 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4]  

PeerSync.java: why "completeList" in handleVersions()?

[Ramsey Haddad]

Does "!completeList" do anything necessary in the line:

if (!completeList && Math.abs(otherVersion) < ourLowThreshold) break;

I think the line should simply be:

if (Math.abs(otherVersion) < ourLowThreshold) break;

-
The inclusion of "!completeList" in this conditional would seem to
only cause some minor performance penalty: replaying a bunch of ADDs
that the syncing replica already has ADDed.

BUT: in our set-up this is causing a noticeable problem. In
particular, we use a large value of nUpdates and we have an hourly DBQ
for garbage collection. If we do rolling restarts of our replicas,
then the second restart can leave us leaderless for a long span of
time.

This happens as follows:
* Replica1 is leader. Replica1 goes down.
* Leadership goes to Replica2. It resyncs with all replicas except Replica1.
* Replica1 returns and resyncs.
* Replica2 is leader. Replica2 goes down.
* Leadership goes to Replica3. It resyncs with all replicas except Replica2.

At this point, Replica1 has a longer updatelog (less trimmed -- more
old updates) than the other replicas. We will refer to these as the
"ancient" updates.
Replica3 does a getVersion from Replica1 and Replica4 and receives
replies from them. The ancient updates will not be contained in
ourUpdateSet. While the ancient updates are older than
ourLowThreshold, the check is skipped because of the "completeList"
term that make no sense to me. So Replica3 replays the ancient ADDs.
Say that 1000 of these ADDs are older than a DBQ in Replica3's update
log? Then the DBQ gets replayed 1000 times ... once after each ADD is
replayed. Fixing the replay mechanism to only replay the DBQ once
looks hard because of the code structure. However, these ADDs (and
hence the DBQ) shouldn't have even been replayed at all!

After the leader Replica3 is synced. It asks Replica 1 and Replica4 to
sync to it. The ancient ADDs have now been merged back unto Replica3's
update log and so when Replica4 is syncing with Replica3, then
Replica4 also ends up replaying the ancient ADDs and replaying the DBQ
1000 times.

Only when all of this finally completes can Replica3 finally perform
its role as leader and accept new updates.

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

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

[Policeman Jenkins Server]

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

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

Error Message:
No registered leader was found after waiting for 6ms , collection: 
c8n_1x3_lf slice: shard1

Stack Trace:
org.apache.solr.common.SolrException: No registered leader was found after 
waiting for 6ms , collection: c8n_1x3_lf slice: shard1
at 
__randomizedtesting.SeedInfo.seed([B98D68286A31CFBA:31D957F2C4CDA242]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderRetry(ZkStateReader.java:616)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:148)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Commented] (SOLR-8737) Managed synonym lists do not include the original term in the expand

[JIRA]

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

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

Hints from mailing list that people have had issues with current behavior:
http://find.searchhub.org/document/bd969ff7efacf642
http://find.searchhub.org/document/8dfce8a277de0f2a

> Managed synonym lists do not include the original term in the expand
> 
>
> Key: SOLR-8737
> URL: https://issues.apache.org/jira/browse/SOLR-8737
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.5
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 5.5.1
>
> Attachments: SOLR-8737.patch
>
>
> Spinoff from discussion in solr-user list 
> http://find.searchhub.org/document/8dfce8a277de0f2a
> The managed synonyms filter does not behave the same way as the original 
> synonym filter when a list is added. The original synonyms filter with 
> default {{expand=true}} produces the following map when parsing a line:
> Input:
> {noformat}
>   a, b, c
> {noformat}
> Becomes:
> {noformat}
>   a => a, b, c
>   b => a, b, c
>   c => a, b, c
> {noformat}
> But the managed filter excludes the original term in the mapping, so an input 
> {{\["a", "b", "c"\]}} becomes:
> {noformat}
>   a => b, c
>   b => a, c
>   c => a, b
> {noformat}
> This can also be seen in {{TestManagedSynonymFilterFactory.java}} where it is 
> tested explicitly, while the tests for the file based synonymfilter expect an 
> all-way expand including the original term.
> This causes a query for "a" to *not* match documents with the term "a", but 
> only those with term "b" or "c".
> The offending line in {{ManagedSynonymFilterFactory}} is this
> {code}
> 188:   treeTerms.remove(origTerm);
> {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] [Assigned] (SOLR-8737) Managed synonym lists do not include the original term in the expand

[JIRA]

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

Jan Høydahl reassigned SOLR-8737:
-

Assignee: Jan Høydahl

> Managed synonym lists do not include the original term in the expand
> 
>
> Key: SOLR-8737
> URL: https://issues.apache.org/jira/browse/SOLR-8737
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.5
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 5.5.1
>
> Attachments: SOLR-8737.patch
>
>
> Spinoff from discussion in solr-user list 
> http://find.searchhub.org/document/8dfce8a277de0f2a
> The managed synonyms filter does not behave the same way as the original 
> synonym filter when a list is added. The original synonyms filter with 
> default {{expand=true}} produces the following map when parsing a line:
> Input:
> {noformat}
>   a, b, c
> {noformat}
> Becomes:
> {noformat}
>   a => a, b, c
>   b => a, b, c
>   c => a, b, c
> {noformat}
> But the managed filter excludes the original term in the mapping, so an input 
> {{\["a", "b", "c"\]}} becomes:
> {noformat}
>   a => b, c
>   b => a, c
>   c => a, b
> {noformat}
> This can also be seen in {{TestManagedSynonymFilterFactory.java}} where it is 
> tested explicitly, while the tests for the file based synonymfilter expect an 
> all-way expand including the original term.
> This causes a query for "a" to *not* match documents with the term "a", but 
> only those with term "b" or "c".
> The offending line in {{ManagedSynonymFilterFactory}} is this
> {code}
> 188:   treeTerms.remove(origTerm);
> {code}



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

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

[jira] [Updated] (SOLR-8737) Managed synonym lists do not include the original term in the expand

[JIRA]

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

Jan Høydahl updated SOLR-8737:
--
Attachment: SOLR-8737.patch

Trivial patch with updated tests which pass.

> Managed synonym lists do not include the original term in the expand
> 
>
> Key: SOLR-8737
> URL: https://issues.apache.org/jira/browse/SOLR-8737
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.5
>Reporter: Jan Høydahl
> Fix For: 5.5.1
>
> Attachments: SOLR-8737.patch
>
>
> Spinoff from discussion in solr-user list 
> http://find.searchhub.org/document/8dfce8a277de0f2a
> The managed synonyms filter does not behave the same way as the original 
> synonym filter when a list is added. The original synonyms filter with 
> default {{expand=true}} produces the following map when parsing a line:
> Input:
> {noformat}
>   a, b, c
> {noformat}
> Becomes:
> {noformat}
>   a => a, b, c
>   b => a, b, c
>   c => a, b, c
> {noformat}
> But the managed filter excludes the original term in the mapping, so an input 
> {{\["a", "b", "c"\]}} becomes:
> {noformat}
>   a => b, c
>   b => a, c
>   c => a, b
> {noformat}
> This can also be seen in {{TestManagedSynonymFilterFactory.java}} where it is 
> tested explicitly, while the tests for the file based synonymfilter expect an 
> all-way expand including the original term.
> This causes a query for "a" to *not* match documents with the term "a", but 
> only those with term "b" or "c".
> The offending line in {{ManagedSynonymFilterFactory}} is this
> {code}
> 188:   treeTerms.remove(origTerm);
> {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] (LUCENE-7049) merge eats CPU much when there are many deleteByQuery

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on LUCENE-7049:
--

I have noticed that deleteByQuery in Solr will be held up by a merge.  That 
roadblock probably also stands in the way of any further indexing requests made 
after the deleteByQuery.  I would not be overly surprised to learn that it 
makes the CPU spin, but I have not actually checked this.

Adds and deletes by ID can happen at the same time as a merge since 4.0, but 
deleteByQuery apparently works differently, so it is blocked by any merge 
activity.  I recently changed my indexing program so that it turns 
deleteByQuery into a query with fl=unique_key_field, and then does the ID 
delete with the results.  I had gotten rid of all the "optimizeUnderway" 
checking that I had added back in the 3.x days, and didn't want to add that 
back in, so I "fixed" my delete code.

> merge eats CPU much when there are many deleteByQuery 
> --
>
> Key: LUCENE-7049
> URL: https://issues.apache.org/jira/browse/LUCENE-7049
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index, core/search
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: Selection_114.png, Selection_115.png, Selection_116.png
>
>
> h2. When
> adding very many delete> 
> h2. Then
> we got CPU spike in merge thread that blocks indexing process
>  
> h2. Considerations
> Despite adding too many  is odd itself, I suppose [the code 
> can more 
> efficient|https://issues.apache.org/jira/browse/LUCENE-5666?focusedCommentId=15129040=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15129040].
>  See sampling snapshots attached. 



--
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-8737) Managed synonym lists do not include the original term in the expand

[JIRA]

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

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

Any comment [~thelabdude]? In SOLR-6878 there is a discussion about how this 
should work, but somewhere along the way something went wrong..

> Managed synonym lists do not include the original term in the expand
> 
>
> Key: SOLR-8737
> URL: https://issues.apache.org/jira/browse/SOLR-8737
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.5
>Reporter: Jan Høydahl
> Fix For: 5.5.1
>
>
> Spinoff from discussion in solr-user list 
> http://find.searchhub.org/document/8dfce8a277de0f2a
> The managed synonyms filter does not behave the same way as the original 
> synonym filter when a list is added. The original synonyms filter with 
> default {{expand=true}} produces the following map when parsing a line:
> Input:
> {noformat}
>   a, b, c
> {noformat}
> Becomes:
> {noformat}
>   a => a, b, c
>   b => a, b, c
>   c => a, b, c
> {noformat}
> But the managed filter excludes the original term in the mapping, so an input 
> {{\["a", "b", "c"\]}} becomes:
> {noformat}
>   a => b, c
>   b => a, c
>   c => a, b
> {noformat}
> This can also be seen in {{TestManagedSynonymFilterFactory.java}} where it is 
> tested explicitly, while the tests for the file based synonymfilter expect an 
> all-way expand including the original term.
> This causes a query for "a" to *not* match documents with the term "a", but 
> only those with term "b" or "c".
> The offending line in {{ManagedSynonymFilterFactory}} is this
> {code}
> 188:   treeTerms.remove(origTerm);
> {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-8729) Querying using a standard query parser on a copied field and highlighting hangs indefinitely

[Jean-Renaud Margelidon (JIRA)]

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

Jean-Renaud Margelidon commented on SOLR-8729:
--

The servers are on two different networks (eth0: 192.168.100.2x and eth1:  
192.168.101.2x)

> Querying using a standard query parser on a copied field and highlighting 
> hangs indefinitely 
> -
>
> Key: SOLR-8729
> URL: https://issues.apache.org/jira/browse/SOLR-8729
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4.1
> Environment: Debian wheezy x64, 4 processors, 4gb memory, 4 SOLR 
> clouds servers
>Reporter: Jean-Renaud Margelidon
>
> On SOLR cloud, I've created a new collection using the 
> sample_techproducts_configs config (2 shards, 2 replicas)
> On that collection, I've crated a single document containing an ID (value 1) 
> and a content field (containing some text).
> When I make a query, using the dismax parser (qf=text) and activating the 
> highlighting, defining the field list to content (hl.fl=content), the result 
> is good.
> Doing the same query with the standard query parser hangs indefinitely 



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/114/
Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
Exactly one shard should have changed, instead: [shard2, shard1] 
nodes=([core_node3(shard2), core_node2(shard1), core_node4(shard1)]) 
expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: Exactly one shard should have changed, instead: 
[shard2, shard1] nodes=([core_node3(shard2), core_node2(shard1), 
core_node4(shard1)]) expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([7657838E9E5FF27D:FE03BC5430A39F85]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.test(DistribDocExpirationUpdateProcessorTest.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[jira] [Created] (SOLR-8737) Managed synonym lists do not include the original term in the expand

[JIRA]

Jan Høydahl created SOLR-8737:
-

 Summary: Managed synonym lists do not include the original term in 
the expand
 Key: SOLR-8737
 URL: https://issues.apache.org/jira/browse/SOLR-8737
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Affects Versions: 5.5
Reporter: Jan Høydahl
 Fix For: 5.5.1


Spinoff from discussion in solr-user list 
http://find.searchhub.org/document/8dfce8a277de0f2a

The managed synonyms filter does not behave the same way as the original 
synonym filter when a list is added. The original synonyms filter with default 
{{expand=true}} produces the following map when parsing a line:

Input:
{noformat}
  a, b, c
{noformat}

Becomes:
{noformat}
  a => a, b, c
  b => a, b, c
  c => a, b, c
{noformat}

But the managed filter excludes the original term in the mapping, so an input 
{{\["a", "b", "c"\]}} becomes:

{noformat}
  a => b, c
  b => a, c
  c => a, b
{noformat}

This can also be seen in {{TestManagedSynonymFilterFactory.java}} where it is 
tested explicitly, while the tests for the file based synonymfilter expect an 
all-way expand including the original term.

This causes a query for "a" to *not* match documents with the term "a", but 
only those with term "b" or "c".

The offending line in {{ManagedSynonymFilterFactory}} is this
{code}
188:   treeTerms.remove(origTerm);
{code}



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

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

[jira] [Created] (SOLR-8736) GET operations on fields, dynamicFields, fieldTypes, copyField should work

[Noble Paul (JIRA)]

Noble Paul created SOLR-8736:


 Summary: GET operations on fields, dynamicFields, fieldTypes, 
copyField should work
 Key: SOLR-8736
 URL: https://issues.apache.org/jira/browse/SOLR-8736
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Minor






--
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-6594) deprecate the one action only APIs for schema editing

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-6594:
--

bq.To be clear, read-only GET operations on the above-mentioned endpoints will 
not be changed, deprecated or removed - they will continue to return 
information about fields, dynamicFields, fieldTypes, and copyField rules, 
respectively.

We need to add these support . I have opened SOLR-8736

> deprecate the one action only APIs for schema editing
> -
>
> Key: SOLR-6594
> URL: https://issues.apache.org/jira/browse/SOLR-6594
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
> Fix For: 5.5, 6.0
>
>
> with SOLR-6476 done and committed , we have more than one way of writing to 
> schema . Having two different ways of doing the same thing is counter 
> productive . 
> I would like to mark them as deprecated and the calls to those APIs will 
> succeed but will give a deprecation message in the output.  The read APIs 
> would continue to be the same , though .
> Details: the following operations have been deprecated as of Solr 5.5, and 
> support for them will be removed in Solr 6.0: 
> * Create new field(s): POST to {{/_collection_/schema/fields}} or PUT to 
> {{/_collection_/schema/fields/_fieldname_}}
> * Create new dynamic field(s): POST to {{/_collection_/schema/dynamicfields}} 
> or PUT to {{/_collection_/schema/dynamicfields/_glob_}}
> * Create new field type(s): POST to {{/_collection_/schema/fieldtypes}} or 
> PUT to {{/_collection_/schema/fieldtypes/_name_}}
> * Create new copyField rule(s): POST to {{/_collection_/schema/copyfields}}.
> Note that all of the above operations can instead be performed using the bulk 
> schema API, documented since the 5.0 Solr ref guide here: 
> https://cwiki.apache.org/confluence/display/solr/Schema+API
> To be clear, read-only GET operations on the above-mentioned endpoints will 
> not be changed, deprecated or removed - they will continue to return 
> information about fields, dynamicFields, fieldTypes, and copyField rules, 
> respectively.



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

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

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

[Policeman Jenkins Server]

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

6 tests failed.
FAILED:  
org.apache.solr.handler.component.TestDistributedStatsComponentCardinality.test

Error Message:
int_i: goodEst=13945, poorEst=13970, real=13974, 
p=q=id:[271+TO+14244]=0=true={!cardinality%3D0.017551397597990737+key%3Dlow_int_i}int_i={!cardinality%3D0.017551397597990737+key%3Dlow_int_i_prehashed_l+hllPreHashed%3Dtrue}int_i_prehashed_l={!cardinality%3D0.5175513975979907+key%3Dhigh_int_i}int_i={!cardinality%3D0.5175513975979907+key%3Dhigh_int_i_prehashed_l+hllPreHashed%3Dtrue}int_i_prehashed_l={!cardinality%3D0.017551397597990737+key%3Dlow_long_l}long_l={!cardinality%3D0.017551397597990737+key%3Dlow_long_l_prehashed_l+hllPreHashed%3Dtrue}long_l_prehashed_l={!cardinality%3D0.5175513975979907+key%3Dhigh_long_l}long_l={!cardinality%3D0.5175513975979907+key%3Dhigh_long_l_prehashed_l+hllPreHashed%3Dtrue}long_l_prehashed_l={!cardinality%3D0.017551397597990737+key%3Dlow_string_s}string_s={!cardinality%3D0.017551397597990737+key%3Dlow_string_s_prehashed_l+hllPreHashed%3Dtrue}string_s_prehashed_l={!cardinality%3D0.5175513975979907+key%3Dhigh_string_s}string_s={!cardinality%3D0.5175513975979907+key%3Dhigh_string_s_prehashed_l+hllPreHashed%3Dtrue}string_s_prehashed_l

Stack Trace:
java.lang.AssertionError: int_i: goodEst=13945, poorEst=13970, real=13974, 
p=q=id:[271+TO+14244]=0=true={!cardinality%3D0.017551397597990737+key%3Dlow_int_i}int_i={!cardinality%3D0.017551397597990737+key%3Dlow_int_i_prehashed_l+hllPreHashed%3Dtrue}int_i_prehashed_l={!cardinality%3D0.5175513975979907+key%3Dhigh_int_i}int_i={!cardinality%3D0.5175513975979907+key%3Dhigh_int_i_prehashed_l+hllPreHashed%3Dtrue}int_i_prehashed_l={!cardinality%3D0.017551397597990737+key%3Dlow_long_l}long_l={!cardinality%3D0.017551397597990737+key%3Dlow_long_l_prehashed_l+hllPreHashed%3Dtrue}long_l_prehashed_l={!cardinality%3D0.5175513975979907+key%3Dhigh_long_l}long_l={!cardinality%3D0.5175513975979907+key%3Dhigh_long_l_prehashed_l+hllPreHashed%3Dtrue}long_l_prehashed_l={!cardinality%3D0.017551397597990737+key%3Dlow_string_s}string_s={!cardinality%3D0.017551397597990737+key%3Dlow_string_s_prehashed_l+hllPreHashed%3Dtrue}string_s_prehashed_l={!cardinality%3D0.5175513975979907+key%3Dhigh_string_s}string_s={!cardinality%3D0.5175513975979907+key%3Dhigh_string_s_prehashed_l+hllPreHashed%3Dtrue}string_s_prehashed_l
at 
__randomizedtesting.SeedInfo.seed([5E3789EDE98E860C:D663B6374772EBF4]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.component.TestDistributedStatsComponentCardinality.test(TestDistributedStatsComponentCardinality.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:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 

Re: Solr Schema API: Deprecation warning for GET operations?

[Noble Paul]

yeah GET should work. The old REST methods served by the restlet
should now be ported over to the SchemaHandler.

I shall open a JIRA and track this



On Thu, Feb 25, 2016 at 3:12 PM, Upayavira  wrote:
> I think you are supposed to be using the bulk api. I think that is what
> the new UI is using.
>
> On Thu, Feb 25, 2016, at 01:18 AM, Alexandre Rafalovitch wrote:
>> Hello,
>>
>> I am using Solr 5.5 and getting deprecation warning when hitting with
>> GET /collection/schema/fieldtypes/name
>>
>> I am confused. In the SOLR-6594, we deprecated PUT/POST, but
>> explicitly said that GET is ok.
>>
>> But if it is ok, why am I getting a warning:
>> . "warn":"This API is deprecated"}
>>
>> Is there a better GET/read API I should be using instead?
>>
>> Regards,
>>Alex.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



-- 
-
Noble Paul

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

[jira] [Commented] (SOLR-8734) fix deprecation warnings for absent (maxMergeDocs|mergeFactor)

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8734:
---

bq. ... to detect the existence of  element in the .xml, and not 
compare the value to the default. ...

If I understood you right this means to distinguish
{code}
...
-1
...
...
{code}
from
{code}
...
{code}
where -1 is the default value for the  element. The motivation 
perhaps being that when SOLR-8668 removes  (and ) 
element support the {{-1}} likely would remain 
behind as a zombie element?

Might we go even further than detecting the existence of a deprecated 
 element and detect any and all unsupported elements? Unsupported 
elements could be simple typos on part of the user e.g. {{}} 
instead of {{}} or they could be misplaced elements e.g. 
[test-files/solr/collection1/conf/solrconfig-spellcheckcomponent.xml|https://github.com/apache/lucene-solr/blob/master/solr/core/src/test-files/solr/collection1/conf/solrconfig-spellcheckcomponent.xml#L34]
 seems to have {{indexConfig/query/maxWarmingSearchers}} when possibly 
{{query/maxWarmingSearchers}} was intended (SOLR-8682 exists for that).


> fix deprecation warnings for absent (maxMergeDocs|mergeFactor)
> --
>
> Key: SOLR-8734
> URL: https://issues.apache.org/jira/browse/SOLR-8734
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, master
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8734.patch, SOLR-8734.patch
>
>
> [~markus17] wrote on the solr-user mailing list:
> bq. 5.5.0 SOLR-8621 deprecation warnings without maxMergeDocs or mergeFactor
> ...
> bq. o.a.s.c.Config Beginning with Solr 5.5,  is deprecated, 
> configure it on the relevant  instead.
> ...
> bq. On my development machine for all cores. None of the cores has either 
> parameter configured. Is this expected?
> ...
> [~cpoerschke] replied:
> ...
> bq. Could you advise if/that the solrconfig.xml has a  element 
> (for which deprecated warnings would appear separately) or that the 
> solrconfig.xml has no  element?
> ...
> bq. If either is the case then yes based on the code 
> (SolrIndexConfig.java#L153) the warnings would be expected-and-harmless 
> though admittedly are confusing, and fixable.
> ...



--
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-7048) Add XXXPoint.newSetQuery to match a set of points

[Michael McCandless (JIRA)]

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

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

New patch, fixing nocommits.

I didn't add the multi-dim'd versions to all {{XXXPoint}} fields, but I did add 
test cases showing that it works and showing how we could add it "for real" 
later.

I think it's ready.

> Add XXXPoint.newSetQuery to match a set of points
> -
>
> Key: LUCENE-7048
> URL: https://issues.apache.org/jira/browse/LUCENE-7048
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master, 6.0
>
> Attachments: LUCENE-7048.patch, LUCENE-7048.patch
>
>
> This is the analog of {{TermsQuery}} for dimensional points, to (relatively) 
> efficiently match any docs whose point value is in the specified set.



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

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

[JENKINS] Lucene-Solr-5.5-Linux (64bit/jdk1.8.0_72) - Build # 113 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/113/
Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseSerialGC

No tests ran.

Build Log:
[...truncated 22 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: 
org.eclipse.jgit.api.errors.TransportException: Connection reset
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:639)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:764)
... 11 more
Caused by: org.eclipse.jgit.api.errors.TransportException: Connection reset
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:637)
... 12 more
Caused by: org.eclipse.jgit.errors.TransportException: Connection reset
at 
org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefs(BasePackConnection.java:182)
at 
org.eclipse.jgit.transport.TransportGitAnon$TcpFetchConnection.(TransportGitAnon.java:194)
at 
org.eclipse.jgit.transport.TransportGitAnon.openFetch(TransportGitAnon.java:120)
at 
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
at 
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
... 13 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
at org.eclipse.jgit.util.IO.readFully(IO.java:246)
at 
org.eclipse.jgit.transport.PacketLineIn.readLength(PacketLineIn.java:186)
at 
org.eclipse.jgit.transport.PacketLineIn.readString(PacketLineIn.java:138)
at 
org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefsImpl(BasePackConnection.java:195)
at 
org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefs(BasePackConnection.java:176)
... 19 more
ERROR: null
Retrying after 10 seconds
Fetching changes from the remote Git repository
Cleaning workspace
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: 
org.eclipse.jgit.api.errors.TransportException: Connection reset
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:639)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:764)
... 11 more
Caused by: org.eclipse.jgit.api.errors.TransportException: Connection reset
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:637)
... 12 more
Caused by: org.eclipse.jgit.errors.TransportException: Connection 

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.CollectionStateFormat2Test.test

Error Message:
No live SolrServers available to handle this request:[http://127.0.0.1:32854, 
http://127.0.0.1:37903, http://127.0.0.1:59036, http://127.0.0.1:54945, 
http://127.0.0.1:41334]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:32854, http://127.0.0.1:37903, 
http://127.0.0.1:59036, http://127.0.0.1:54945, http://127.0.0.1:41334]
at 
__randomizedtesting.SeedInfo.seed([722C917743CB8527:FA78AEADED37E8DF]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1547)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1808)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.testConfNameAndCollectionNameSame(CollectionStateFormat2Test.java:52)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.test(CollectionStateFormat2Test.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Commented] (SOLR-8734) fix deprecation warnings for absent (maxMergeDocs|mergeFactor)

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-8734:
--

Patch looks good. Even while working on the previous issue I thought that we 
should be able to detect the existence of {{}} element in the 
.xml, and not compare the value to the default. What happens if someone 
includes both {{}} and {{}} set to the default 
value? Would we also fail?

> fix deprecation warnings for absent (maxMergeDocs|mergeFactor)
> --
>
> Key: SOLR-8734
> URL: https://issues.apache.org/jira/browse/SOLR-8734
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, master
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8734.patch, SOLR-8734.patch
>
>
> [~markus17] wrote on the solr-user mailing list:
> bq. 5.5.0 SOLR-8621 deprecation warnings without maxMergeDocs or mergeFactor
> ...
> bq. o.a.s.c.Config Beginning with Solr 5.5,  is deprecated, 
> configure it on the relevant  instead.
> ...
> bq. On my development machine for all cores. None of the cores has either 
> parameter configured. Is this expected?
> ...
> [~cpoerschke] replied:
> ...
> bq. Could you advise if/that the solrconfig.xml has a  element 
> (for which deprecated warnings would appear separately) or that the 
> solrconfig.xml has no  element?
> ...
> bq. If either is the case then yes based on the code 
> (SolrIndexConfig.java#L153) the warnings would be expected-and-harmless 
> though admittedly are confusing, and fixable.
> ...



--
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-8734) fix deprecation warnings for absent (maxMergeDocs|mergeFactor)

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-8734:
--
Attachment: SOLR-8734.patch

Simplified/Tweaked proposed patch a little.

> fix deprecation warnings for absent (maxMergeDocs|mergeFactor)
> --
>
> Key: SOLR-8734
> URL: https://issues.apache.org/jira/browse/SOLR-8734
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, master
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8734.patch, SOLR-8734.patch
>
>
> [~markus17] wrote on the solr-user mailing list:
> bq. 5.5.0 SOLR-8621 deprecation warnings without maxMergeDocs or mergeFactor
> ...
> bq. o.a.s.c.Config Beginning with Solr 5.5,  is deprecated, 
> configure it on the relevant  instead.
> ...
> bq. On my development machine for all cores. None of the cores has either 
> parameter configured. Is this expected?
> ...
> [~cpoerschke] replied:
> ...
> bq. Could you advise if/that the solrconfig.xml has a  element 
> (for which deprecated warnings would appear separately) or that the 
> solrconfig.xml has no  element?
> ...
> bq. If either is the case then yes based on the code 
> (SolrIndexConfig.java#L153) the warnings would be expected-and-harmless 
> though admittedly are confusing, and fixable.
> ...



--
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-8234) Federated Search (new) - DJoin

[Tom Winch (JIRA)]

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

Tom Winch commented on SOLR-8234:
-

That would be another approach, I guess.  You'd still have to write the 
(custom) merge code, and the approach of this JIRA means you get back SOLR 
results as per usual, and it's a plugin that makes use of the existing 
distributed search mechanisms for requesting the top N unique ids from each 
server and merge-ranking them etc.

> Federated Search (new) - DJoin
> --
>
> Key: SOLR-8234
> URL: https://issues.apache.org/jira/browse/SOLR-8234
> Project: Solr
>  Issue Type: New Feature
>Reporter: Tom Winch
>Priority: Minor
>  Labels: federated_search
> Fix For: 4.10.3
>
> Attachments: SOLR-8234.patch, SOLR-8234.patch, SOLR-8234.patch
>
>
> This issue describes a MergeStrategy implementation (DJoin) to facilitate 
> federated search - that is, distributed search over documents stored in 
> separated instances of SOLR (for example, one server per continent), where a 
> single document (identified by an agreed, common unique id) may be stored in 
> more than one server instance, with (possibly) differing fields and data.
> When the MergeStrategy is used in a request handler (via the included 
> QParser) in combination with distributed search (shards=), documents having 
> an id that has already been seen are not discarded (as per the default 
> behaviour) but, instead, are collected and returned as a group of documents 
> all with the same id taking a single position in the result set (this is 
> implemented using parent/child documents, with an indicator field in the 
> parent - see example output, below).
> Documents are sorted in the result set based on the highest ranking document 
> with the same id. It is possible for a document ranking high in one shard to 
> rank very low on another shard. As a consequence of this, all shards must be 
> asked to return the fields for every document id in the result set (not just 
> of those documents they returned), so that all the component parts of each 
> document in the search result set are returned.
> As usual, search parameters are passed on to each shard. So that the shards 
> do not need any additional configurations in their definition of the /select 
> request handler, we use the FilterQParserSearchComponent which is configured 
> to filter out the \{!djoin\} search parameter - otherwise, the target request 
> handler complains about the missing query parser definition. See the example 
> config, below.
> This issue combines with others to provide full federated search support. See 
> also SOLR-8235 and SOLR-8236.
> Note that this is part of a new implementation of federated search as opposed 
> to the older issues SOLR-3799 through SOLR-3805.
> --
> Example request handler configuration:
> {code:xml}
>class="org.apache.solr.search.federated.FilterDJoinQParserSearchComponent" />
>   
>class="org.apache.solr.search.federated.DJoinQParserPlugin" />
>   
> 
>name="shards">http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
>   true
>   {!djoin}
> 
> 
>   filter
> 
>
> {code}
> Example output:
> {code:xml}
> 
> 
>   
> 0
> 33
> 
>   *:*
>name="shards">http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
>   true
>   xml
>   {!djoin}
>   *,[shard]
> 
>   
>   
> 
>   true
>   
> 200
> 1973
> http://shard2/solr/core
> 1515645309629235200
>   
>   
> 200
> 2015
> http://shard1/solr/core
> 1515645309682712576
>   
> 
> 
>   true
>   
> 100
> 873
> http://shard1/solr/core
> 1515645309629254124
>   
>   
> 100
> 2001
> http://shard3/solr/core
> 1515645309682792852
>   
> 
> 
>   true
>   
> 300
> 1492
> http://shard2/solr/core
> 1515645309629251252
>   
> 
>   
> 
> {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

Re: Solr Schema API: Deprecation warning for GET operations?

[Upayavira]

I think you are supposed to be using the bulk api. I think that is what
the new UI is using.

On Thu, Feb 25, 2016, at 01:18 AM, Alexandre Rafalovitch wrote:
> Hello,
> 
> I am using Solr 5.5 and getting deprecation warning when hitting with
> GET /collection/schema/fieldtypes/name
> 
> I am confused. In the SOLR-6594, we deprecated PUT/POST, but
> explicitly said that GET is ok.
> 
> But if it is ok, why am I getting a warning:
> . "warn":"This API is deprecated"}
> 
> Is there a better GET/read API I should be using instead?
> 
> Regards,
>Alex.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

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

[jira] [Commented] (SOLR-8730) Experimental UI, the hl.fl is not properly set doing queries

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-8730:
-

Fix should be trivial, will get to it when i can.

> Experimental UI, the hl.fl is not properly set doing queries
> 
>
> Key: SOLR-8730
> URL: https://issues.apache.org/jira/browse/SOLR-8730
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4.1
> Environment: Debian wheezy x64, 4 processors, 4gb memory, 4 SOLR 
> clouds servers
>Reporter: Jean-Renaud Margelidon
>Assignee: Upayavira
>Priority: Minor
>
> When using the experiment UI and doing searches on collection, when 
> populating the hl.fl field, the value is used for the fl instead.
> URL generated:
> http://127.0.0.1/solr/collection/select?fl=content=on=on=html=json
> URL Expected:
> http://127.0.0.1/solr/collection/select?hl.fl=content=on=on=html=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] [Assigned] (SOLR-8730) Experimental UI, the hl.fl is not properly set doing queries

[Upayavira (JIRA)]

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

Upayavira reassigned SOLR-8730:
---

Assignee: Upayavira

> Experimental UI, the hl.fl is not properly set doing queries
> 
>
> Key: SOLR-8730
> URL: https://issues.apache.org/jira/browse/SOLR-8730
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4.1
> Environment: Debian wheezy x64, 4 processors, 4gb memory, 4 SOLR 
> clouds servers
>Reporter: Jean-Renaud Margelidon
>Assignee: Upayavira
>Priority: Minor
>
> When using the experiment UI and doing searches on collection, when 
> populating the hl.fl field, the value is used for the fl instead.
> URL generated:
> http://127.0.0.1/solr/collection/select?fl=content=on=on=html=json
> URL Expected:
> http://127.0.0.1/solr/collection/select?hl.fl=content=on=on=html=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

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.CollectionStateFormat2Test.test

Error Message:
No live SolrServers available to handle this request:[http://127.0.0.1:49782, 
http://127.0.0.1:48461, http://127.0.0.1:53528, http://127.0.0.1:36475, 
http://127.0.0.1:37894]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:49782, http://127.0.0.1:48461, 
http://127.0.0.1:53528, http://127.0.0.1:36475, http://127.0.0.1:37894]
at 
__randomizedtesting.SeedInfo.seed([97693D800122E083:1F3D025AAFDE8D7B]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1547)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1808)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.testConfNameAndCollectionNameSame(CollectionStateFormat2Test.java:52)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.test(CollectionStateFormat2Test.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

RE: ant idea and IntelliJ 15

[Uwe Schindler]

We also have a Maven build already!

 

Uwe

 

-

Uwe Schindler

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

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Jan Høydahl [mailto:jan@cominvent.com] 
Sent: Thursday, February 25, 2016 1:50 AM
To: dev@lucene.apache.org
Subject: Re: ant idea and IntelliJ 15

 

It now works for me after running “ant clean-idea idea”. Sorry for the noise :)

 

@Martin, I have no problem with building with Ant, so I’m sorry I cannot assist 
in your maven effort.

 

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com  

 

24. feb. 2016 kl. 14.26 skrev Kevin Risden  >:

 

 

On Wed, Feb 24, 2016 at 3:47 AM, Jan Høydahl  > wrote:

Not sure if the problem started after I upgraded to IntelliJ 15 or after we 
switched to git or what. Others having the same issues?


I haven't had any issues using IntellJ 14, 15 or 16 EAP with lucene-solr before 
or after switching to Git. I've cloned and cleaned out the IntelliJ settings 
multiple times and haven't had any issues opening the project in IntelliJ after 
doing "ant idea".



Kevin Risden
Hadoop Tech Lead |   Avalon Consulting, LLC

M: 732 213 8417

  LinkedIn |  
 Google+ |  
 Twitter

 

-

This message (including any attachments) contains confidential information 

intended for a specific individual and purpose, and is protected by law. If 

you are not the intended recipient, you should delete this message. Any 

disclosure, copying, or distribution of this message, or the taking of any 

action based on it, is strictly prohibited.

 

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.CollectionStateFormat2Test.test

Error Message:
No live SolrServers available to handle this request:[http://127.0.0.1:39023, 
http://127.0.0.1:33290, http://127.0.0.1:38200, http://127.0.0.1:57072, 
http://127.0.0.1:37227]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:39023, http://127.0.0.1:33290, 
http://127.0.0.1:38200, http://127.0.0.1:57072, http://127.0.0.1:37227]
at 
__randomizedtesting.SeedInfo.seed([C9DE50F751E25631:418A6F2DFF1E3BC9]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1547)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1808)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.testConfNameAndCollectionNameSame(CollectionStateFormat2Test.java:52)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.test(CollectionStateFormat2Test.java:40)
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:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Commented] (LUCENE-5666) Add UninvertingReader

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-5666:
--

followup LUCENE-7049 

> Add UninvertingReader
> -
>
> Key: LUCENE-5666
> URL: https://issues.apache.org/jira/browse/LUCENE-5666
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: 5.0, master
>
> Attachments: LUCENE-5666.patch
>
>
> Currently the fieldcache is not pluggable at all. It would be better if 
> everything used the docvalues apis.
> This would allow people to customize the implementation, extend the classes 
> with custom subclasses with additional stuff, etc etc.
> FieldCache can be accessed via the docvalues apis, using the FilterReader api.



--
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-7049) merge eats CPU much when there are many deleteByQuery

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-7049:
-
Attachment: Selection_116.png
Selection_115.png
Selection_114.png

Thanks [~ivan.mamontov] for contributing snapshots. 

> merge eats CPU much when there are many deleteByQuery 
> --
>
> Key: LUCENE-7049
> URL: https://issues.apache.org/jira/browse/LUCENE-7049
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index, core/search
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: Selection_114.png, Selection_115.png, Selection_116.png
>
>
> h2. When
> adding very many delete> 
> h2. Then
> we got CPU spike in merge thread that blocks indexing process
>  
> h2. Considerations
> Despite adding too many  is odd itself, I suppose [the code 
> can more 
> efficient|https://issues.apache.org/jira/browse/LUCENE-5666?focusedCommentId=15129040=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15129040].
>  See sampling snapshots attached. 



--
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-7049) merge eats CPU much when there many deleteByQuery

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-7049:
-
Summary: merge eats CPU much when there many deleteByQuery   (was: merage 
eats CPU much when there many deleteByQuery )

> merge eats CPU much when there many deleteByQuery 
> --
>
> Key: LUCENE-7049
> URL: https://issues.apache.org/jira/browse/LUCENE-7049
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index, core/search
>Reporter: Mikhail Khludnev
>Priority: Minor
>
> h2. When
> adding very many delete> 
> h2. Then
> we got CPU spike in merge thread that blocks indexing process
>  
> h2. Considerations
> Despite adding too many  is odd itself, I suppose [the code 
> can more 
> efficient|https://issues.apache.org/jira/browse/LUCENE-5666?focusedCommentId=15129040=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15129040].
>  See sampling snapshots attached. 



--
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-7049) merge eats CPU much when there are many deleteByQuery

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-7049:
-
Summary: merge eats CPU much when there are many deleteByQuery   (was: 
merge eats CPU much when there many deleteByQuery )

> merge eats CPU much when there are many deleteByQuery 
> --
>
> Key: LUCENE-7049
> URL: https://issues.apache.org/jira/browse/LUCENE-7049
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index, core/search
>Reporter: Mikhail Khludnev
>Priority: Minor
>
> h2. When
> adding very many delete> 
> h2. Then
> we got CPU spike in merge thread that blocks indexing process
>  
> h2. Considerations
> Despite adding too many  is odd itself, I suppose [the code 
> can more 
> efficient|https://issues.apache.org/jira/browse/LUCENE-5666?focusedCommentId=15129040=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15129040].
>  See sampling snapshots attached. 



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

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

[jira] [Created] (LUCENE-7049) merage eats CPU much when there many deleteByQuery

[Mikhail Khludnev (JIRA)]

Mikhail Khludnev created LUCENE-7049:


 Summary: merage eats CPU much when there many deleteByQuery 
 Key: LUCENE-7049
 URL: https://issues.apache.org/jira/browse/LUCENE-7049
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/index, core/search
Reporter: Mikhail Khludnev
Priority: Minor


h2. When
adding very many delete> 

h2. Then
we got CPU spike in merge thread that blocks indexing process
 
h2. Considerations
Despite adding too many  is odd itself, I suppose [the code can 
more 
efficient|https://issues.apache.org/jira/browse/LUCENE-5666?focusedCommentId=15129040=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15129040].
 See sampling snapshots attached. 



--
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-8735) Fix CheckHdfsIndexTest test failure

[Gregory Chanan (JIRA)]

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

Gregory Chanan resolved SOLR-8735.
--
   Resolution: Fixed
Fix Version/s: 6.0

Thanks [~mdrob], committed to trunk.  I held off committing to 5.x because it's 
not clear to me what's going on there...there's no 5.5.1 or 5.6.0 version in 
jira.  This is safe for 6.0 in any case.

> Fix CheckHdfsIndexTest test failure
> ---
>
> Key: SOLR-8735
> URL: https://issues.apache.org/jira/browse/SOLR-8735
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Gregory Chanan
>  Labels: jenkins, unit-test
> Fix For: 6.0
>
> Attachments: SOLR-8735.patch
>
>
> I was going to post this on SOLR-7928 but the "Attach File" button is gone 
> for some reason.
> There are some failures from this on Jenkins -- 
> https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3977/
> I think we need to give Solr more time to start up before we begin indexing, 
> patch coming shortly.
> I was not able to find any failures on 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-8735) Fix CheckHdfsIndexTest test failure

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8735: Fix CheckHdfsIndexTest test failure


> Fix CheckHdfsIndexTest test failure
> ---
>
> Key: SOLR-8735
> URL: https://issues.apache.org/jira/browse/SOLR-8735
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Gregory Chanan
>  Labels: jenkins, unit-test
> Attachments: SOLR-8735.patch
>
>
> I was going to post this on SOLR-7928 but the "Attach File" button is gone 
> for some reason.
> There are some failures from this on Jenkins -- 
> https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3977/
> I think we need to give Solr more time to start up before we begin indexing, 
> patch coming shortly.
> I was not able to find any failures on 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] [Updated] (SOLR-8735) Fix CheckHdfsIndexTest test failure

[Gregory Chanan (JIRA)]

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

Gregory Chanan updated SOLR-8735:
-
Summary: Fix CheckHdfsIndexTest test failure  (was: 
org.apache.solr.index.hdfs.CheckHdfsIndexTest.doTest test failure)

> Fix CheckHdfsIndexTest test failure
> ---
>
> Key: SOLR-8735
> URL: https://issues.apache.org/jira/browse/SOLR-8735
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Gregory Chanan
>  Labels: jenkins, unit-test
> Attachments: SOLR-8735.patch
>
>
> I was going to post this on SOLR-7928 but the "Attach File" button is gone 
> for some reason.
> There are some failures from this on Jenkins -- 
> https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3977/
> I think we need to give Solr more time to start up before we begin indexing, 
> patch coming shortly.
> I was not able to find any failures on 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-5.5-MacOSX (64bit/jdk1.7.0) - Build # 11 - Failure!

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 45 
seconds
at 
__randomizedtesting.SeedInfo.seed([5FB735E6B7AA4A0A:D7E30A3C195627F2]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:174)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:836)
at 
org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.test(DistribDocExpirationUpdateProcessorTest.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Assigned] (SOLR-8735) org.apache.solr.index.hdfs.CheckHdfsIndexTest.doTest test failure

[Gregory Chanan (JIRA)]

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

Gregory Chanan reassigned SOLR-8735:


Assignee: Gregory Chanan

> org.apache.solr.index.hdfs.CheckHdfsIndexTest.doTest test failure
> -
>
> Key: SOLR-8735
> URL: https://issues.apache.org/jira/browse/SOLR-8735
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Gregory Chanan
>  Labels: jenkins, unit-test
> Attachments: SOLR-8735.patch
>
>
> I was going to post this on SOLR-7928 but the "Attach File" button is gone 
> for some reason.
> There are some failures from this on Jenkins -- 
> https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3977/
> I think we need to give Solr more time to start up before we begin indexing, 
> patch coming shortly.
> I was not able to find any failures on 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