[jira] [Commented] (SOLR-6755) ClassCastException from CloudMLTQParserTest

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-6755:


I'll take a look.

> ClassCastException from CloudMLTQParserTest
> ---
>
> Key: SOLR-6755
> URL: https://issues.apache.org/jira/browse/SOLR-6755
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Anshum Gupta
> Attachments: SOLR-6755.patch
>
>
> The seed doesn't reproduce for me, but the ClassCastException seems hinky and 
> worth looking into...
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=CloudMLTQParserTest -Dtests.method=testDistribSearch 
> -Dtests.seed=3AE918BB008859A6 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=iw -Dtests.timezone=America/Indiana/Vincennes 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   50.7s J1 | CloudMLTQParserTest.testDistribSearch <<<
>[junit4]> Throwable #1: java.lang.ClassCastException: java.lang.String 
> cannot be cast to java.util.ArrayList
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3AE918BB008859A6:BB0F96A377D7399A]:0)
>[junit4]>  at 
> org.apache.solr.search.mlt.CloudMLTQParserTest.doTest(CloudMLTQParserTest.java:124)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11466/consoleText
> Java: 64bit/jdk1.7.0_67 -XX:-UseCompressedOops -XX:+UseG1GC (asserts: true)
> At revision 1640267



--
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.9.0-ea-b60) - Build # 12454 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12454/
Java: 64bit/jdk1.9.0-ea-b60 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
ERROR: SolrIndexSearcher opens=51 closes=50

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50
at __randomizedtesting.SeedInfo.seed([B0C30CE9E1F4218E]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:496)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:232)
at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:502)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=6906, name=searcherExecutor-2788-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=6906, name=searcherExecutor-2788-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 __randomizedtesting.SeedInfo.seed([B0C30CE9E1F4218E]:0)


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

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

[jira] [Resolved] (SOLR-7421) RecoveryAfterSoftCommitTest fails frequently on Jenkins due to full index replication taking longer than 30 seconds

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-7421.
-
   Resolution: Fixed
Fix Version/s: Trunk

Last failure was 8 days ago.

> RecoveryAfterSoftCommitTest fails frequently on Jenkins due to full index 
> replication taking longer than 30 seconds
> ---
>
> Key: SOLR-7421
> URL: https://issues.apache.org/jira/browse/SOLR-7421
> Project: Solr
>  Issue Type: Bug
>Reporter: Timothy Potter
>Assignee: Shalin Shekhar Mangar
>Priority: Blocker
> Fix For: Trunk, 5.2
>
> Attachments: RecoveryAfterSoftCommitTest_failure.log, 
> SOLR-7421.patch, SOLR-7421.patch
>
>
> RecoveryAfterSoftCommitTest is failing frequently on Jenkins because the test 
> only gives 30 seconds for the replica to recover after healing the partition. 
> It looks like it's taking >30 seconds to replicate the full index from the 
> leader (the test is designed so that peer sync can't work). It seems bad that 
> it takes >30 seconds to replicate an index with only 115 documents in it ... 
> wonder if there is cruft laying around from other tests? I've run beast on 
> this test locally and it always passes. What's weird is I see log messages 
> like:
> {code}
>[junit4]   2> 1436627 T4242 N:127.0.0.1:63274_ecb%2Fay C476 
> oash.IndexFetcher.fetchLatestIndex Number of files in latest index in master: 
> 263
> {code}
> 263 files for an index with 115 docs? Doesn't seem right!



--
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] [Reopened] (SOLR-6755) ClassCastException from CloudMLTQParserTest

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar reopened SOLR-6755:
-

This happened again on jenkins.

http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12237/

{code}
1 tests failed.
FAILED:  org.apache.solr.search.mlt.CloudMLTQParserTest.test

Error Message:
java.lang.String cannot be cast to java.util.ArrayList

Stack Trace:
java.lang.ClassCastException: java.lang.String cannot be cast to 
java.util.ArrayList
at 
__randomizedtesting.SeedInfo.seed([AA2D16A20519A653:22792978ABE5CBAB]:0)
at 
org.apache.solr.search.mlt.CloudMLTQParserTest.test(CloudMLTQParserTest.java:138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
{code}

> ClassCastException from CloudMLTQParserTest
> ---
>
> Key: SOLR-6755
> URL: https://issues.apache.org/jira/browse/SOLR-6755
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Anshum Gupta
> Attachments: SOLR-6755.patch
>
>
> The seed doesn't reproduce for me, but the ClassCastException seems hinky and 
> worth looking into...
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=CloudMLTQParserTest -Dtests.method=testDistribSearch 
> -Dtests.seed=3AE918BB008859A6 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=iw -Dtests.timezone=America/Indiana/Vincennes 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   50.7s J1 | CloudMLTQParserTest.testDistribSearch <<<
>[junit4]> Throwable #1: java.lang.ClassCastException: java.lang.String 
> cannot be cast to java.util.ArrayList
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3AE918BB008859A6:BB0F96A377D7399A]:0)
>[junit4]>  at 
> org.apache.solr.search.mlt.CloudMLTQParserTest.doTest(CloudMLTQParserTest.java:124)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11466/consoleText
> Java: 64bit/jdk1.7.0_67 -XX:-UseCompressedOops -XX:+UseG1GC (asserts: true)
> At revision 1640267



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

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.handler.component.DistributedMLTComponentTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:23259//collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:23259//collection1
at 
__randomizedtesting.SeedInfo.seed([DA88FC81E91109EA:52DCC35B47ED6412]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:570)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:558)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:606)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:588)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:567)
at 
org.apache.solr.handler.component.DistributedMLTComponentTest.test(DistributedMLTComponentTest.java:126)
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:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAd

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

[Policeman Jenkins Server]

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

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

Error Message:
IOException occured when talking to server at: 
https://127.0.0.1:56240/solr/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:56240/solr/collection1
at __randomizedtesting.SeedInfo.seed([A2B3DE4E97CD5889]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:574)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:483)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:464)
at 
org.apache.solr.handler.component.DistributedDebugComponentTest.createThings(DistributedDebugComponentTest.java:90)
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:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:776)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.http.NoHttpResponseException: 127.0.0.1:56240 failed to 
respond
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
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.h

[jira] [Commented] (SOLR-7452) json facet api returning inconsistent counts in cloud set up

[Vamsi Krishna D (JIRA)]

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

Vamsi Krishna D commented on SOLR-7452:
---

Thanks for the update Yonik! 

> json facet api returning inconsistent counts in cloud set up
> 
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>  Labels: count, facet, sort
> Fix For: 5.2
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api 
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent 
> returns of counts of faceted value ( Note I am running on a cloud mode of 
> solr). For example consider that i have txns_id(unique field or key), 
> consumer_number and amount. Now for a 10 million such records , lets say i 
> query for 
> q=*:*&rows=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
>   "numBuckets":3112708,
>   "buckets":[{
>   "val":"surya",
>   "count":4,
>   "y":2.264506},
>   {
>   "val":"raghu",
>   "COUNT":3,   // capitalised for recognition 
>   "y":1.8},
> {
>   "val":"malli",
>   "count":4,
>   "y":1.78}]}}}
> but if i restrict the query to 
> q=consumer_number:raghu&rows=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> i get :
>   "facets":{
> "count":4,
> "biskatoo":{
>   "numBuckets":1,
>   "buckets":[{
>   "val":"raghu",
>   "COUNT":4,
>   "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions 
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but 
> still the issue seems not resolved



--
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-7452) json facet api returning inconsistent counts in cloud set up

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-7452:


Hi Vamsi,
The behavior you are seeing is because we haven't yet implemented facet 
refinement.  Currently, the distributed statistics are a result of simply 
combining the top N buckets from each shard, which can result in a small amount 
of error.  It's definitely on the roadmap to implement this!

> json facet api returning inconsistent counts in cloud set up
> 
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>  Labels: count, facet, sort
> Fix For: 5.2
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api 
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent 
> returns of counts of faceted value ( Note I am running on a cloud mode of 
> solr). For example consider that i have txns_id(unique field or key), 
> consumer_number and amount. Now for a 10 million such records , lets say i 
> query for 
> q=*:*&rows=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
>   "numBuckets":3112708,
>   "buckets":[{
>   "val":"surya",
>   "count":4,
>   "y":2.264506},
>   {
>   "val":"raghu",
>   "COUNT":3,   // capitalised for recognition 
>   "y":1.8},
> {
>   "val":"malli",
>   "count":4,
>   "y":1.78}]}}}
> but if i restrict the query to 
> q=consumer_number:raghu&rows=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> i get :
>   "facets":{
> "count":4,
> "biskatoo":{
>   "numBuckets":1,
>   "buckets":[{
>   "val":"raghu",
>   "COUNT":4,
>   "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions 
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but 
> still the issue seems not resolved



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

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

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

[Apache Jenkins Server]

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

1 tests failed.
REGRESSION:  org.apache.solr.handler.component.DistributedMLTComponentTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:36167//collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:36167//collection1
at 
__randomizedtesting.SeedInfo.seed([EF6A4F27C34BA123:673E70FD6DB7CCDB]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:570)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:558)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:606)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:588)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:567)
at 
org.apache.solr.handler.component.DistributedMLTComponentTest.test(DistributedMLTComponentTest.java:126)
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:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.Stateme

[jira] [Commented] (SOLR-7446) Facet Module Internal Improvements

[ASF subversion and git services (JIRA)]

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

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

Commit 1676078 from [~yo...@apache.org] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1676078 ]

SOLR-7446: refactor range faceting to use slots

> Facet Module Internal Improvements
> --
>
> Key: SOLR-7446
> URL: https://issues.apache.org/jira/browse/SOLR-7446
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.1
>Reporter: Yonik Seeley
> Fix For: 5.2
>
>
> Parent issue for new facet module (JSON Facet API) internal improvements.



--
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-7446) Facet Module Internal Improvements

[ASF subversion and git services (JIRA)]

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

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

Commit 1676077 from [~yo...@apache.org] in branch 'dev/trunk'
[ https://svn.apache.org/r1676077 ]

SOLR-7446: refactor range faceting to use slots

> Facet Module Internal Improvements
> --
>
> Key: SOLR-7446
> URL: https://issues.apache.org/jira/browse/SOLR-7446
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.1
>Reporter: Yonik Seeley
> Fix For: 5.2
>
>
> Parent issue for new facet module (JSON Facet API) internal improvements.



--
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_45) - Build # 12451 - Failure!

[Policeman Jenkins Server]

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

3 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=7168, 
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)2) Thread[id=7167, 
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)3) Thread[id=7171, 
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 
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=7172, 
name=NioSocketAcceptor-1, state=RUNNABLE, group=TGRP-SaslZkACLProviderTest] 
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at 
sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at 
sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) 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.apache.mina.transport.socket.nio.NioSocketAcceptor.select(NioSocketAcceptor.java:234)
 at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:417)
 at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) 
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)5) Thread[id=7170, 
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=7169, 
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)

[jira] [Resolved] (SOLR-5213) collections?action=SPLITSHARD parent vs. sub-shards numDocs

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar resolved SOLR-5213.
-
   Resolution: Fixed
Fix Version/s: 5.2

Thanks Christine!

> collections?action=SPLITSHARD parent vs. sub-shards numDocs
> ---
>
> Key: SOLR-5213
> URL: https://issues.apache.org/jira/browse/SOLR-5213
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 4.4
>Reporter: Christine Poerschke
>Assignee: Ramkumar Aiyengar
> Fix For: 5.2
>
> Attachments: SOLR-5213.patch, SOLR-5213.patch
>
>
> The problem we saw was that splitting a shard took a long time and at the end 
> of it the sub-shards contained fewer documents than the original shard.
> The root cause was eventually tracked down to the disappearing documents not 
> falling into the hash ranges of the sub-shards.
> Could SolrIndexSplitter split report per-segment numDocs for parent and 
> sub-shards, with at least a warning logged for any discrepancies (documents 
> falling into none of the sub-shards or documents falling into several 
> sub-shards)?
> Additionally, could a case be made for erroring out when discrepancies are 
> detected i.e. not proceeding with the shard split? Either to always error or 
> to have an verifyNumDocs=false/true optional parameter for the SPLITSHARD 
> action.



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

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

[jira] [Comment Edited] (SOLR-7377) SOLR Streaming Expressions

[Dennis Gove (JIRA)]

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

Dennis Gove edited comment on SOLR-7377 at 4/26/15 12:29 AM:
-

Made ParallelStream an ExpressibleStream and modified the StreamHandler to 
accept stream expression strings instead of bytecode.

Refactored operation and operand into functionName and parameter. And 
refactored all required references and tangentially related variable/class 
names.

Renamed EqualToComparator to FieldComparator to be a little more descriptive in 
the name.

Added ability to support pluggable streams by making it something you can 
configure in solrconfig.xml.

All stream-related tests pass. At this point I'd consider this functionally 
complete. 


was (Author: dpgove):
Made ParallelStream an ExpressibleStream and modified the StreamHandler to 
accept stream expression strings instead of bytecode.

Refactored operation and operand into functionName and parameter. And 
refactored all required references and tangentially related variable/class 
names.

Renamed EqualToComparator to FieldComparator to be a little more descriptive in 
the name.

Added ability to support pluggable streams by making it something you can 
configure in solrconfig.xml.

> SOLR Streaming Expressions
> --
>
> Key: SOLR-7377
> URL: https://issues.apache.org/jira/browse/SOLR-7377
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Reporter: Dennis Gove
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7377.patch, SOLR-7377.patch
>
>
> It would be beneficial to add an expression-based interface to Streaming API 
> described in SOLR-7082. Right now that API requires streaming requests to 
> come in from clients as serialized bytecode of the streaming classes. The 
> suggestion here is to support string expressions which describe the streaming 
> operations the client wishes to perform. 
> {code:java}
> search(collection1, q=*:*, fl="id,fieldA,fieldB", sort="fieldA asc")
> {code}
> With this syntax in mind, one can now express arbitrarily complex stream 
> queries with a single string.
> {code:java}
> // merge two distinct searches together on common fields
> merge(
>   search(collection1, q="id:(0 3 4)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s 
> asc"),
>   search(collection2, q="id:(1 2)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s 
> asc"),
>   on="a_f asc, a_s asc")
> // find top 20 unique records of a search
> top(
>   n=20,
>   unique(
> search(collection1, q=*:*, fl="id,a_s,a_i,a_f", sort="a_f desc"),
> over="a_f desc"),
>   sort="a_f desc")
> {code}
> The syntax would support
> 1. Configurable expression names (eg. via solrconfig.xml one can map "unique" 
> to a class implementing a Unique stream class) This allows users to build 
> their own streams and use as they wish.
> 2. Named parameters (of both simple and expression types)
> 3. Unnamed, type-matched parameters (to support requiring N streams as 
> arguments to another stream)
> 4. Positional parameters
> The main goal here is to make streaming as accessible as possible and define 
> a syntax for running complex queries across large distributed systems.



--
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-7377) SOLR Streaming Expressions

[Dennis Gove (JIRA)]

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

Dennis Gove updated SOLR-7377:
--
Attachment: SOLR-7377.patch

Made ParallelStream an ExpressibleStream and modified the StreamHandler to 
accept stream expression strings instead of bytecode.

Refactored operation and operand into functionName and parameter. And 
refactored all required references and tangentially related variable/class 
names.

Renamed EqualToComparator to FieldComparator to be a little more descriptive in 
the name.

Added ability to support pluggable streams by making it something you can 
configure in solrconfig.xml.

> SOLR Streaming Expressions
> --
>
> Key: SOLR-7377
> URL: https://issues.apache.org/jira/browse/SOLR-7377
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Reporter: Dennis Gove
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7377.patch, SOLR-7377.patch
>
>
> It would be beneficial to add an expression-based interface to Streaming API 
> described in SOLR-7082. Right now that API requires streaming requests to 
> come in from clients as serialized bytecode of the streaming classes. The 
> suggestion here is to support string expressions which describe the streaming 
> operations the client wishes to perform. 
> {code:java}
> search(collection1, q=*:*, fl="id,fieldA,fieldB", sort="fieldA asc")
> {code}
> With this syntax in mind, one can now express arbitrarily complex stream 
> queries with a single string.
> {code:java}
> // merge two distinct searches together on common fields
> merge(
>   search(collection1, q="id:(0 3 4)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s 
> asc"),
>   search(collection2, q="id:(1 2)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s 
> asc"),
>   on="a_f asc, a_s asc")
> // find top 20 unique records of a search
> top(
>   n=20,
>   unique(
> search(collection1, q=*:*, fl="id,a_s,a_i,a_f", sort="a_f desc"),
> over="a_f desc"),
>   sort="a_f desc")
> {code}
> The syntax would support
> 1. Configurable expression names (eg. via solrconfig.xml one can map "unique" 
> to a class implementing a Unique stream class) This allows users to build 
> their own streams and use as they wish.
> 2. Named parameters (of both simple and expression types)
> 3. Unnamed, type-matched parameters (to support requiring N streams as 
> arguments to another stream)
> 4. Positional parameters
> The main goal here is to make streaming as accessible as possible and define 
> a syntax for running complex queries across large distributed systems.



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

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

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_45) - Build # 4729 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4729/
Java: 32bit/jdk1.8.0_45 -server -XX:+UseG1GC

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

Error Message:
ERROR: SolrIndexSearcher opens=51 closes=50

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50
at __randomizedtesting.SeedInfo.seed([71DAEF6C54C3F340]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:496)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:232)
at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=553, name=searcherExecutor-535-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=553, name=searcherExecutor-535-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 __randomizedtesting.SeedInfo.seed([71DAEF6C54C3F340]:0)


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

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=553, name=searcherExecutor-535-thread

[jira] [Commented] (SOLR-5213) collections?action=SPLITSHARD parent vs. sub-shards numDocs

[ASF subversion and git services (JIRA)]

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

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

Commit 1676076 from [~andyetitmoves] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1676076 ]

SOLR-5213: Log when shard splitting unexpectedly leads to documents going to 
zero or multiple sub-shards

> collections?action=SPLITSHARD parent vs. sub-shards numDocs
> ---
>
> Key: SOLR-5213
> URL: https://issues.apache.org/jira/browse/SOLR-5213
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 4.4
>Reporter: Christine Poerschke
>Assignee: Ramkumar Aiyengar
> Attachments: SOLR-5213.patch, SOLR-5213.patch
>
>
> The problem we saw was that splitting a shard took a long time and at the end 
> of it the sub-shards contained fewer documents than the original shard.
> The root cause was eventually tracked down to the disappearing documents not 
> falling into the hash ranges of the sub-shards.
> Could SolrIndexSplitter split report per-segment numDocs for parent and 
> sub-shards, with at least a warning logged for any discrepancies (documents 
> falling into none of the sub-shards or documents falling into several 
> sub-shards)?
> Additionally, could a case be made for erroring out when discrepancies are 
> detected i.e. not proceeding with the shard split? Either to always error or 
> to have an verifyNumDocs=false/true optional parameter for the SPLITSHARD 
> action.



--
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-5213) collections?action=SPLITSHARD parent vs. sub-shards numDocs

[ASF subversion and git services (JIRA)]

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

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

Commit 1676075 from [~andyetitmoves] in branch 'dev/trunk'
[ https://svn.apache.org/r1676075 ]

SOLR-5213: Log when shard splitting unexpectedly leads to documents going to 
zero or multiple sub-shards

> collections?action=SPLITSHARD parent vs. sub-shards numDocs
> ---
>
> Key: SOLR-5213
> URL: https://issues.apache.org/jira/browse/SOLR-5213
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 4.4
>Reporter: Christine Poerschke
>Assignee: Ramkumar Aiyengar
> Attachments: SOLR-5213.patch, SOLR-5213.patch
>
>
> The problem we saw was that splitting a shard took a long time and at the end 
> of it the sub-shards contained fewer documents than the original shard.
> The root cause was eventually tracked down to the disappearing documents not 
> falling into the hash ranges of the sub-shards.
> Could SolrIndexSplitter split report per-segment numDocs for parent and 
> sub-shards, with at least a warning logged for any discrepancies (documents 
> falling into none of the sub-shards or documents falling into several 
> sub-shards)?
> Additionally, could a case be made for erroring out when discrepancies are 
> detected i.e. not proceeding with the shard split? Either to always error or 
> to have an verifyNumDocs=false/true optional parameter for the SPLITSHARD 
> action.



--
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-5213) collections?action=SPLITSHARD parent vs. sub-shards numDocs

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar updated SOLR-5213:

Attachment: SOLR-5213.patch

Brought this up to date and fixed a bug when ranges is null..

> collections?action=SPLITSHARD parent vs. sub-shards numDocs
> ---
>
> Key: SOLR-5213
> URL: https://issues.apache.org/jira/browse/SOLR-5213
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 4.4
>Reporter: Christine Poerschke
>Assignee: Ramkumar Aiyengar
> Attachments: SOLR-5213.patch, SOLR-5213.patch
>
>
> The problem we saw was that splitting a shard took a long time and at the end 
> of it the sub-shards contained fewer documents than the original shard.
> The root cause was eventually tracked down to the disappearing documents not 
> falling into the hash ranges of the sub-shards.
> Could SolrIndexSplitter split report per-segment numDocs for parent and 
> sub-shards, with at least a warning logged for any discrepancies (documents 
> falling into none of the sub-shards or documents falling into several 
> sub-shards)?
> Additionally, could a case be made for erroring out when discrepancies are 
> detected i.e. not proceeding with the shard split? Either to always error or 
> to have an verifyNumDocs=false/true optional parameter for the SPLITSHARD 
> action.



--
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-5213) collections?action=SPLITSHARD parent vs. sub-shards numDocs

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar reassigned SOLR-5213:
---

Assignee: Ramkumar Aiyengar  (was: Shalin Shekhar Mangar)

> collections?action=SPLITSHARD parent vs. sub-shards numDocs
> ---
>
> Key: SOLR-5213
> URL: https://issues.apache.org/jira/browse/SOLR-5213
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 4.4
>Reporter: Christine Poerschke
>Assignee: Ramkumar Aiyengar
> Attachments: SOLR-5213.patch, SOLR-5213.patch
>
>
> The problem we saw was that splitting a shard took a long time and at the end 
> of it the sub-shards contained fewer documents than the original shard.
> The root cause was eventually tracked down to the disappearing documents not 
> falling into the hash ranges of the sub-shards.
> Could SolrIndexSplitter split report per-segment numDocs for parent and 
> sub-shards, with at least a warning logged for any discrepancies (documents 
> falling into none of the sub-shards or documents falling into several 
> sub-shards)?
> Additionally, could a case be made for erroring out when discrepancies are 
> detected i.e. not proceeding with the shard split? Either to always error or 
> to have an verifyNumDocs=false/true optional parameter for the SPLITSHARD 
> action.



--
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-6068) solr: timing-debug to include lucene-search-time

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-6068:


Interesting.  I presume this time, "lucene search time", is a sub-part of 
QueryComponent's "query" time.  If so, what notable things would show up in the 
"query" time but not "lucene search time"?  Maybe filter query execution?

> solr: timing-debug to include lucene-search-time
> 
>
> Key: SOLR-6068
> URL: https://issues.apache.org/jira/browse/SOLR-6068
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Ramkumar Aiyengar
>
> github pull request with the proposed change to follow.



--
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-7391) Use a time based expiration cache for one off hdfs FileSystem instances.

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-7391: Use a time based expiration cache for one off HDFS FileSystem 
instances.

> Use a time based expiration cache for one off hdfs FileSystem instances.
> 
>
> Key: SOLR-7391
> URL: https://issues.apache.org/jira/browse/SOLR-7391
> Project: Solr
>  Issue Type: Improvement
>  Components: hdfs, s
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-7391.patch
>
>
> Most FileSystem clients are tied to a SolrCore and long lived, but in some 
> cases where we don't have SolrCore context we create a short lived hdfs 
> client object.
> Because these instances can be created via user generated actions, we don't 
> want to be able to create too many of them - they have overhead that does not 
> make them great candidates for being spun up for a single call.



--
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-7391) Use a time based expiration cache for one off hdfs FileSystem instances.

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-7391: Use a time based expiration cache for one off HDFS FileSystem 
instances.

> Use a time based expiration cache for one off hdfs FileSystem instances.
> 
>
> Key: SOLR-7391
> URL: https://issues.apache.org/jira/browse/SOLR-7391
> Project: Solr
>  Issue Type: Improvement
>  Components: hdfs, s
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-7391.patch
>
>
> Most FileSystem clients are tied to a SolrCore and long lived, but in some 
> cases where we don't have SolrCore context we create a short lived hdfs 
> client object.
> Because these instances can be created via user generated actions, we don't 
> want to be able to create too many of them - they have overhead that does not 
> make them great candidates for being spun up for a single call.



--
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-7446) Facet Module Internal Improvements

[ASF subversion and git services (JIRA)]

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

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

Commit 1676071 from [~yo...@apache.org] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1676071 ]

SOLR-7446: refactor range faceting to create range list first

> Facet Module Internal Improvements
> --
>
> Key: SOLR-7446
> URL: https://issues.apache.org/jira/browse/SOLR-7446
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.1
>Reporter: Yonik Seeley
> Fix For: 5.2
>
>
> Parent issue for new facet module (JSON Facet API) internal improvements.



--
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-7446) Facet Module Internal Improvements

[ASF subversion and git services (JIRA)]

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

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

Commit 1676069 from [~yo...@apache.org] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1676069 ]

SOLR-7446: refactor range faceting to create range list first

> Facet Module Internal Improvements
> --
>
> Key: SOLR-7446
> URL: https://issues.apache.org/jira/browse/SOLR-7446
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.1
>Reporter: Yonik Seeley
> Fix For: 5.2
>
>
> Parent issue for new facet module (JSON Facet API) internal improvements.



--
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-7446) Facet Module Internal Improvements

[ASF subversion and git services (JIRA)]

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

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

Commit 1676066 from [~yo...@apache.org] in branch 'dev/trunk'
[ https://svn.apache.org/r1676066 ]

SOLR-7446: refactor range faceting to create range list first

> Facet Module Internal Improvements
> --
>
> Key: SOLR-7446
> URL: https://issues.apache.org/jira/browse/SOLR-7446
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.1
>Reporter: Yonik Seeley
> Fix For: 5.2
>
>
> Parent issue for new facet module (JSON Facet API) internal improvements.



--
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-7429) Remove Solr server module sync-hack introduced in SOLR-4050.

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-7429.
--
Resolution: Fixed

The 5.x smoke tester succeeded on ASF Jenkins: 
https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/259/

> Remove Solr server module sync-hack introduced in SOLR-4050.
> 
>
> Key: SOLR-7429
> URL: https://issues.apache.org/jira/browse/SOLR-7429
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-7429-fix-servlet-api-deps.patch, 
> SOLR-7429.more.servlet.api.jar.fixes.patch, SOLR-7429.patch
>
>
> This is annoying to the beast script I have and for other obvious reasons. We 
> would really like to use sync=true here like everywhere. I'll see what I can 
> do.



--
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-7118) ChaosMonkeyNothingIsSafeTest fails with too many update fails

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-7118: Raise fail tolerance.

> ChaosMonkeyNothingIsSafeTest fails with too many update fails
> -
>
> Key: SOLR-7118
> URL: https://issues.apache.org/jira/browse/SOLR-7118
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud, Tests
>Affects Versions: 5.0
>Reporter: Shalin Shekhar Mangar
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-7118.patch
>
>
> There are frequent failures on both trunk and branch_5x with the following 
> message:
> {code}
> java.lang.AssertionError: There were too many update fails - we expect it can 
> happen, but shouldn't easily
>   at 
> __randomizedtesting.SeedInfo.seed([786DB0FD42626C16:F98B3EE5353D0C2A]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at org.junit.Assert.assertTrue(Assert.java:43)
>   at org.junit.Assert.assertFalse(Assert.java:68)
>   at 
> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.doTest(ChaosMonkeyNothingIsSafeTest.java:224)
>   at 
> org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:878)
> {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-7118) ChaosMonkeyNothingIsSafeTest fails with too many update fails

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-7118: Raise fail tolerance.

> ChaosMonkeyNothingIsSafeTest fails with too many update fails
> -
>
> Key: SOLR-7118
> URL: https://issues.apache.org/jira/browse/SOLR-7118
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud, Tests
>Affects Versions: 5.0
>Reporter: Shalin Shekhar Mangar
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-7118.patch
>
>
> There are frequent failures on both trunk and branch_5x with the following 
> message:
> {code}
> java.lang.AssertionError: There were too many update fails - we expect it can 
> happen, but shouldn't easily
>   at 
> __randomizedtesting.SeedInfo.seed([786DB0FD42626C16:F98B3EE5353D0C2A]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at org.junit.Assert.assertTrue(Assert.java:43)
>   at org.junit.Assert.assertFalse(Assert.java:68)
>   at 
> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.doTest(ChaosMonkeyNothingIsSafeTest.java:224)
>   at 
> org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:878)
> {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-5.x-Java7 - Build # 3010 - Failure

[Apache Jenkins Server]

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

1 tests failed.
REGRESSION:  org.apache.solr.search.facet.TestJsonFacets.testComplex

Error Message:
mismatch: 'civic'!='a' @ facets/makes/buckets/[0]/models/buckets/[1]/val

Stack Trace:
java.lang.RuntimeException: mismatch: 'civic'!='a' @ 
facets/makes/buckets/[0]/models/buckets/[1]/val
at 
__randomizedtesting.SeedInfo.seed([9E61A60C86CF0D3D:7FBEA390AA81415E]:0)
at org.apache.solr.SolrTestCaseHS.matchJSON(SolrTestCaseHS.java:160)
at org.apache.solr.SolrTestCaseHS.assertJQ(SolrTestCaseHS.java:142)
at org.apache.solr.SolrTestCaseHS$Client.testJQ(SolrTestCaseHS.java:288)
at 
org.apache.solr.search.facet.TestJsonFacets.testComplex(TestJsonFacets.java:157)
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:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 10419 lines...]
   [junit4] Suite: org.apache.solr.search.facet.TestJsonFacets
   [junit4]   2> Creating dataDir: 
/usr/ho

[jira] [Commented] (SOLR-7118) ChaosMonkeyNothingIsSafeTest fails with too many update fails

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7118:
---

I'm just going to raise it for now.

> ChaosMonkeyNothingIsSafeTest fails with too many update fails
> -
>
> Key: SOLR-7118
> URL: https://issues.apache.org/jira/browse/SOLR-7118
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud, Tests
>Affects Versions: 5.0
>Reporter: Shalin Shekhar Mangar
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-7118.patch
>
>
> There are frequent failures on both trunk and branch_5x with the following 
> message:
> {code}
> java.lang.AssertionError: There were too many update fails - we expect it can 
> happen, but shouldn't easily
>   at 
> __randomizedtesting.SeedInfo.seed([786DB0FD42626C16:F98B3EE5353D0C2A]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at org.junit.Assert.assertTrue(Assert.java:43)
>   at org.junit.Assert.assertFalse(Assert.java:68)
>   at 
> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.doTest(ChaosMonkeyNothingIsSafeTest.java:224)
>   at 
> org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:878)
> {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-7349) Cleanup or fix cloud-dev scripts

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7349:
---

I'd prefer these scripts did not move to using the start scripts yet myself.

I think the most non controversial fix here is the best way - make the simple 
adjustments necessary for jetty 9. I've attached an initial patch for that.

> Cleanup or fix cloud-dev scripts
> 
>
> Key: SOLR-7349
> URL: https://issues.apache.org/jira/browse/SOLR-7349
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Reporter: Ramkumar Aiyengar
>Assignee: Ramkumar Aiyengar
>Priority: Minor
> Fix For: 5.2
>
> Attachments: SOLR-7349.patch, SOLR-7349.patch
>
>
> With Jetty 9, cloud-dev scripts no longer work in trunk, we need to either 
> clean up or fix them.



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

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

[jira] [Updated] (SOLR-7349) Cleanup or fix cloud-dev scripts

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-7349:
--
Attachment: SOLR-7349.patch

> Cleanup or fix cloud-dev scripts
> 
>
> Key: SOLR-7349
> URL: https://issues.apache.org/jira/browse/SOLR-7349
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Reporter: Ramkumar Aiyengar
>Assignee: Ramkumar Aiyengar
>Priority: Minor
> Fix For: 5.2
>
> Attachments: SOLR-7349.patch, SOLR-7349.patch
>
>
> With Jetty 9, cloud-dev scripts no longer work in trunk, we need to either 
> clean up or fix them.



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

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

[jira] [Resolved] (SOLR-7471) Stop requiring docValues for interval faceting

[JIRA]

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

Tomás Fernández Löbbe resolved SOLR-7471.
-
   Resolution: Fixed
Fix Version/s: 5.2
   Trunk

> Stop requiring docValues for interval faceting
> --
>
> Key: SOLR-7471
> URL: https://issues.apache.org/jira/browse/SOLR-7471
> Project: Solr
>  Issue Type: Improvement
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-7471.patch
>
>
> Will use fieldCache if docValues are not present



--
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-4839) Jetty 9

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-4839:

Attachment: SOLR-4839-separate-client-ssl-options.patch

Thanks Steve. I added your suggestions to this patch 
(SOLR-4839-separate-client-ssl-options.patch) to separate the client and Jetty 
SSL config.

I don't think replacing Property with SystemProperty is necessary because 
"Property" can also be set via SystemProperty plus it can also be overridden 
from one of the module files. However the way we're using them both Property 
and SystemProperty are equivalent.

> Jetty 9
> ---
>
> Key: SOLR-4839
> URL: https://issues.apache.org/jira/browse/SOLR-4839
> Project: Solr
>  Issue Type: Improvement
>Reporter: Bill Bell
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-4839-conform-jetty9_2_10.patch, 
> SOLR-4839-conform-jetty9_2_10.patch, SOLR-4839-fix-eclipse.patch, 
> SOLR-4839-jetty9.2.10, SOLR-4839-mod-JettySolrRunner.patch, 
> SOLR-4839-separate-client-ssl-options.patch, 
> SOLR-4839-ssl-support_patch.patch, SOLR-4839-ssl-support_patch.patch, 
> SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, 
> SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, 
> SOLR-4839.patch
>
>
> Implement Jetty 9



--
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_60-ea-b12) - Build # 12447 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12447/
Java: 32bit/jdk1.8.0_60-ea-b12 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.search.facet.TestJsonFacets.testComplex

Error Message:
mismatch: 'accord'!='a' @ facets/makes/buckets/[0]/models/buckets/[1]/val

Stack Trace:
java.lang.RuntimeException: mismatch: 'accord'!='a' @ 
facets/makes/buckets/[0]/models/buckets/[1]/val
at 
__randomizedtesting.SeedInfo.seed([1AAB9F30B329E3B2:FB749AAC9F67AFD1]:0)
at org.apache.solr.SolrTestCaseHS.matchJSON(SolrTestCaseHS.java:160)
at org.apache.solr.SolrTestCaseHS.assertJQ(SolrTestCaseHS.java:142)
at org.apache.solr.SolrTestCaseHS$Client.testJQ(SolrTestCaseHS.java:288)
at 
org.apache.solr.search.facet.TestJsonFacets.testComplex(TestJsonFacets.java:157)
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:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 9291 lines...]
   [junit4] Suite: org.apache.solr.search.facet.TestJso

[jira] [Resolved] (SOLR-7382) SOLR-7241 introduced a partials directory in the root checkout dir.

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved SOLR-7382.
-
Resolution: Fixed
  Assignee: Uwe Schindler  (was: Erick Erickson)

> SOLR-7241 introduced a partials directory in the root checkout dir.
> ---
>
> Key: SOLR-7382
> URL: https://issues.apache.org/jira/browse/SOLR-7382
> Project: Solr
>  Issue Type: Bug
>Reporter: Erick Erickson
>Assignee: Uwe Schindler
>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-7382) SOLR-7241 introduced a partials directory in the root checkout dir.

[ASF subversion and git services (JIRA)]

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

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

Commit 1676042 from [~thetaphi] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1676042 ]

Merged revision(s) 1676041 from lucene/dev/trunk:
SOLR-7382: Nuke partials in root folder

> SOLR-7241 introduced a partials directory in the root checkout dir.
> ---
>
> Key: SOLR-7382
> URL: https://issues.apache.org/jira/browse/SOLR-7382
> Project: Solr
>  Issue Type: Bug
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>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-7382) SOLR-7241 introduced a partials directory in the root checkout dir.

[ASF subversion and git services (JIRA)]

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

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

Commit 1676041 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1676041 ]

SOLR-7382: Nuke partials in root folder

> SOLR-7241 introduced a partials directory in the root checkout dir.
> ---
>
> Key: SOLR-7382
> URL: https://issues.apache.org/jira/browse/SOLR-7382
> Project: Solr
>  Issue Type: Bug
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>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

Re: 16K threads used up, Solr 4.10 doing nothing.

[Erick Erickson]

I'm pretty sure they hadn't. And the stack traces in the jstack
(excerpt above) isn't indicative of the facet code.

The critical bit here is that the server was just sitting around for a
long time, completely and totally idle (dev system so it's only used
intermittently).

Erick

On Sat, Apr 25, 2015 at 2:24 AM, Dmitry Kan  wrote:
> Hi Erick,
>
> Do you know, whether the client used facet.threads, even once?
>
> There's a bug in solr with threaded faceting, that makes use of unlimited
> amount of threads.
>
> Regards,
> Dmitry
>
> On 24 Apr 2015 3:17 am, "Erick Erickson"  wrote:
>>
>> A client had a Solr instance doing absolutely nothing for a month.
>> Literally a test system that was idle. When they tried to finally do
>> something, they couldn't. That Solr process had over 16K threads
>> operating. No indexing, no querying, was going on, nada.
>>
>> They investigated and found that the Solr couldn't connect to
>> Zookeeper and had a zillion threads (well, actually about 16K which
>> was their limit) with the stack trace at the end.
>>
>> Admittedly the client had a weird situation where Solr couldn't talk
>> to Zookeeper, and admittedly Solr can't do much if it can't talk to
>> ZK.
>>
>> Even so this seems odd. I'm also a bit worried that if they fix the
>> reason Solr couldn't talk to ZK (maybe it's a firewall issue? plug the
>> cable back in?) that when all those threads suddenly get to do their
>> thing what will happen? Not to mention any effects on other processes.
>>
>> Anyway, if this is worth a JIRA I can create one if there aren't any
>> already.
>>
>> Solr 4.10
>>
>> Here's the stack trace:
>>
>> "main-EventThread" daemon prio=10 tid=0x0a38d000 nid=0xeb51 in
>> Object.wait() [0x7e8c15c89000]
>>
>>java.lang.Thread.State: TIMED_WAITING (on object monitor)
>>at java.lang.Object.wait(Native Method)
>>at
>> org.apache.solr.common.cloud.ConnectionManager.waitForConnected(ConnectionManager.java:215)
>> - locked <0x0003c5306fc0> (a
>> org.apache.solr.common.cloud.ConnectionManager)
>> at
>> org.apache.solr.common.cloud.ConnectionManager$1.update(ConnectionManager.java:138)
>> at
>> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:56)
>> at
>> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
>> at
>> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
>> at
>> org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
>>
>> Erick
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

Re: partials/ folder in checkout

[Erick Erickson]

Nobody objected so go ahead and nuke it IMO.

On Sat, Apr 25, 2015 at 2:52 AM, Uwe Schindler  wrote:
> Hi,
>
> any news on this. "partials" folder is still there! If nobody objects, I will 
> remove it later this day.
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -Original Message-
>> From: Erick Erickson [mailto:erickerick...@gmail.com]
>> Sent: Sunday, April 12, 2015 10:56 PM
>> To: dev@lucene.apache.org
>> Subject: Re: partials/ folder in checkout
>>
>> I'm tracking that, see SOLR-7382. I suspect it's an accident, will confirm 
>> and
>> remove probably tomorrow unless it's causing people grief.
>>
>> On Sun, Apr 12, 2015 at 11:19 AM, Uwe Schindler  wrote:
>> > Thanks. I just noticed while checking with preview build of
>> > forbiddenapis
>> > 1.8 :)
>> >
>> > Uwe
>> >
>> >
>> > Am 12. April 2015 20:11:17 MESZ, schrieb Shalin Shekhar Mangar
>> > :
>> >>
>> >> Yes, I noticed that too and I commented on the original issue. See
>> >> https://issues.apache.org/jira/browse/SOLR-7241?page=com.atlassian.ji
>> >> ra.plugin.system.issuetabpanels:comment-
>> tabpanel&focusedCommentId=144
>> >> 90844#comment-14490844
>> >>
>> >>
>> >> On Sun, Apr 12, 2015 at 11:32 PM, Uwe Schindler 
>> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> Trunk and branch_5x now contain a strange partials/ folder in the
>> >>> root of the checkout. Is this intended. To me this looks like a
>> >>> relict which was accidentally committed.
>> >>>
>> >>> If this is true, please remove!
>> >>>
>> >>> Uwe
>> >>>
>> >>> -
>> >>> Uwe Schindler
>> >>> H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de
>> >>> eMail: u...@thetaphi.de
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> -
>> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Shalin Shekhar Mangar.
>> >
>> >
>> > --
>> > Uwe Schindler
>> > H.-H.-Meier-Allee 63, 28213 Bremen
>> > http://www.thetaphi.de
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> -
> 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-7429) Remove Solr server module sync-hack introduced in SOLR-4050.

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-7429:
-

Thanks! Its fine that we have this check in smoker. Placing a servlet.jar 
inside a WAR is the biggest no-go ever :-)

> Remove Solr server module sync-hack introduced in SOLR-4050.
> 
>
> Key: SOLR-7429
> URL: https://issues.apache.org/jira/browse/SOLR-7429
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-7429-fix-servlet-api-deps.patch, 
> SOLR-7429.more.servlet.api.jar.fixes.patch, SOLR-7429.patch
>
>
> This is annoying to the beast script I have and for other obvious reasons. We 
> would really like to use sync=true here like everywhere. I'll see what I can 
> do.



--
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-7472) SortingResponseWriter does not log fl parameters that don't exist.

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-7472:


Assignee: Joel Bernstein

> SortingResponseWriter does not log fl parameters that don't exist.
> --
>
> Key: SOLR-7472
> URL: https://issues.apache.org/jira/browse/SOLR-7472
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1, 4.10.2, 4.10.4, 5.0, 5.1
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 5.2
>
> Attachments: SOLR-7472.patch
>
>
> The SortingResponseWriter, which is the response writer for the /export 
> handler, does not log the error that is thrown when an fl is specified that 
> does not exist.
> The reason for this is that an unchecked SolrException is being thrown from 
> the IndexSchema. All other exceptions in SortingResponseWriter are wrapped in 
> an IOException. 
> For reasons I'm not entirely sure of the ResponseUtils class doesn't log the 
> stacktrace for errors with codes between 500 and 100. It considers these to 
> be normal error conditions. So the unchecked SolrException was not being 
> logged.
> The short term fix for this is to catch the exception from the IndexSchema 
> and wrap it in a IOException like the other exceptions from the 
> SortingResponseWriter.
> Longer term I think it makes sense to review the ResponseUtil exception 
> logging logic.



--
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-7441) Streaming aggregation error messages could use some improvement

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-7441:
--

SOLR-7472 has a patch which resolves the fl logging issue. This fix will be in 
5.2.

We can continue to work with Gus's patch in this ticket.

> Streaming aggregation error messages could use some improvement
> ---
>
> Key: SOLR-7441
> URL: https://issues.apache.org/jira/browse/SOLR-7441
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.1
>Reporter: Erick Erickson
>Assignee: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-7441.patch, SOLR-7441.patch
>
>
> It's harder than it could be to figure out what the error is when using 
> Streaming Aggregation. For instance if you specify an fl parameter for a 
> field that doesn't exist it's hard to figure out that's the cause. This is 
> true even if you look in the Solr logs.
> I'm not quite sure whether it'd be possible to report this at the client 
> level or not, but it seems at least we could repor something more helpful in 
> the Solr logs.



--
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-7472) SortingResponseWriter does not log fl parameters that don't exist.

[Joel Bernstein (JIRA)]

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

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

Patch with fix

> SortingResponseWriter does not log fl parameters that don't exist.
> --
>
> Key: SOLR-7472
> URL: https://issues.apache.org/jira/browse/SOLR-7472
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1, 4.10.2, 4.10.4, 5.0, 5.1
>Reporter: Joel Bernstein
> Fix For: 5.2
>
> Attachments: SOLR-7472.patch
>
>
> The SortingResponseWriter, which is the response writer for the /export 
> handler, does not log the error that is thrown when an fl is specified that 
> does not exist.
> The reason for this is that an unchecked SolrException is being thrown from 
> the IndexSchema. All other exceptions in SortingResponseWriter are wrapped in 
> an IOException. 
> For reasons I'm not entirely sure of the ResponseUtils class doesn't log the 
> stacktrace for errors with codes between 500 and 100. It considers these to 
> be normal error conditions. So the unchecked SolrException was not being 
> logged.
> The short term fix for this is to catch the exception from the IndexSchema 
> and wrap it in a IOException like the other exceptions from the 
> SortingResponseWriter.
> Longer term I think it makes sense to review the ResponseUtil exception 
> logging logic.



--
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-7472) SortingResponseWriter does not log fl parameters that don't exist.

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-7472:


 Summary: SortingResponseWriter does not log fl parameters that 
don't exist.
 Key: SOLR-7472
 URL: https://issues.apache.org/jira/browse/SOLR-7472
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1, 5.0, 4.10.4, 4.10.2, 4.10.1, 4.10, 4.9.1, 4.9
Reporter: Joel Bernstein
 Fix For: 5.2


The SortingResponseWriter, which is the response writer for the /export 
handler, does not log the error that is thrown when an fl is specified that 
does not exist.

The reason for this is that an unchecked SolrException is being thrown from the 
IndexSchema. All other exceptions in SortingResponseWriter are wrapped in an 
IOException. 

For reasons I'm not entirely sure of the ResponseUtils class doesn't log the 
stacktrace for errors with codes between 500 and 100. It considers these to be 
normal error conditions. So the unchecked SolrException was not being logged.

The short term fix for this is to catch the exception from the IndexSchema and 
wrap it in a IOException like the other exceptions from the 
SortingResponseWriter.

Longer term I think it makes sense to review the ResponseUtil exception logging 
logic.



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

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

Re: [JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 257 - Still Failing

[Steve Rowe]

I committed a fix and manually scheduled a branch_5x smoke test run on ASF 
Jenkins - it’ll run after the nightly 5.x job running now.
 
> On Apr 25, 2015, at 8:52 AM, Steve Rowe  wrote:
> 
> This is yet another of the SOLR-7429 hydra’s heads.  I’m looking at it.
> 
>> On Apr 25, 2015, at 6:21 AM, Michael McCandless  
>> wrote:
>> 
>> Is anyone looking at this?  Should we disable this "sheisty class" in
>> Solr's WAR?
>> 
>> Mike McCandless
>> 
>> http://blog.mikemccandless.com
>> 
>> 
>> On Fri, Apr 24, 2015 at 7:13 PM, Apache Jenkins Server
>>  wrote:
>>> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/257/
>>> 
>>> No tests ran.
>>> 
>>> Build Log:
>>> [...truncated 52433 lines...]
>>> prepare-release-no-sign:
>>>   [mkdir] Created dir: 
>>> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist
>>>[copy] Copying 446 files to 
>>> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene
>>>[copy] Copying 245 files to 
>>> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr
>>>  [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
>>>  [smoker] NOTE: output encoding is US-ASCII
>>>  [smoker]
>>>  [smoker] Load release URL 
>>> "file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/"...
>>>  [smoker]
>>>  [smoker] Test Lucene...
>>>  [smoker]   test basics...
>>>  [smoker]   get KEYS
>>>  [smoker] 0.1 MB in 0.02 sec (8.4 MB/sec)
>>>  [smoker]   check changes HTML...
>>>  [smoker]   download lucene-5.2.0-src.tgz...
>>>  [smoker] 28.2 MB in 0.04 sec (684.8 MB/sec)
>>>  [smoker] verify md5/sha1 digests
>>>  [smoker]   download lucene-5.2.0.tgz...
>>>  [smoker] 64.8 MB in 0.09 sec (687.8 MB/sec)
>>>  [smoker] verify md5/sha1 digests
>>>  [smoker]   download lucene-5.2.0.zip...
>>>  [smoker] 74.6 MB in 0.13 sec (552.3 MB/sec)
>>>  [smoker] verify md5/sha1 digests
>>>  [smoker]   unpack lucene-5.2.0.tgz...
>>>  [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>>>  [smoker] test demo with 1.7...
>>>  [smoker]   got 5777 hits for query "lucene"
>>>  [smoker] checkindex with 1.7...
>>>  [smoker] check Lucene's javadoc JAR
>>>  [smoker]   unpack lucene-5.2.0.zip...
>>>  [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>>>  [smoker] test demo with 1.7...
>>>  [smoker]   got 5777 hits for query "lucene"
>>>  [smoker] checkindex with 1.7...
>>>  [smoker] check Lucene's javadoc JAR
>>>  [smoker]   unpack lucene-5.2.0-src.tgz...
>>>  [smoker] make sure no JARs/WARs in src dist...
>>>  [smoker] run "ant validate"
>>>  [smoker] run tests w/ Java 7 and 
>>> testArgs='-Dtests.jettyConnector=Socket -Dtests.multiplier=1 
>>> -Dtests.slow=false'...
>>>  [smoker] test demo with 1.7...
>>>  [smoker]   got 208 hits for query "lucene"
>>>  [smoker] checkindex with 1.7...
>>>  [smoker] generate javadocs w/ Java 7...
>>>  [smoker]
>>>  [smoker] Crawl/parse...
>>>  [smoker]
>>>  [smoker] Verify...
>>>  [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
>>>  [smoker] find all past Lucene releases...
>>>  [smoker] run TestBackwardsCompatibility..
>>>  [smoker] success!
>>>  [smoker]
>>>  [smoker] Test Solr...
>>>  [smoker]   test basics...
>>>  [smoker]   get KEYS
>>>  [smoker] 0.1 MB in 0.00 sec (68.5 MB/sec)
>>>  [smoker]   check changes HTML...
>>>  [smoker]   download solr-5.2.0-src.tgz...
>>>  [smoker] 36.0 MB in 0.07 sec (485.0 MB/sec)
>>>  [smoker] verify md5/sha1 digests
>>>  [smoker]   download solr-5.2.0.tgz...
>>>  [smoker] 126.4 MB in 0.21 sec (595.5 MB/sec)
>>>  [smoker] verify md5/sha1 digests
>>>  [smoker]   download solr-5.2.0.zip...
>>>  [smoker] 133.0 MB in 0.15 sec (904.3 MB/sec)
>>>  [smoker] verify md5/sha1 digests
>>>  [smoker]   unpack solr-5.2.0.tgz...
>>>  [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>>>  [smoker] unpack lucene-5.2.0.tgz...
>>>  [smoker]   **WARNING**: skipping check of 
>>> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.2.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
>>>  it has javax.* classes
>>>  [smoker]   **WARNING**: skipping check of 
>>> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.2.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
>>>  it has javax.* classes
>>>  [smoker]   **WARNING**: skipping check of 
>>> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.2.0/server/lib/ext/javax.servlet-api-3.0.1.jar:
>>>  it has javax.* classes
>>>  [smoker]

[jira] [Commented] (SOLR-7429) Remove Solr server module sync-hack introduced in SOLR-4050.

[ASF subversion and git services (JIRA)]

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

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

Commit 1676026 from [~steve_rowe] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1676026 ]

SOLR-7429: Making the servlet-api jar a compile-scope dependency in solr-core 
caused it to be included in the war, where it should not be.  Added 
*javax.servlet* to list of things to exclude from the war.

> Remove Solr server module sync-hack introduced in SOLR-4050.
> 
>
> Key: SOLR-7429
> URL: https://issues.apache.org/jira/browse/SOLR-7429
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-7429-fix-servlet-api-deps.patch, 
> SOLR-7429.more.servlet.api.jar.fixes.patch, SOLR-7429.patch
>
>
> This is annoying to the beast script I have and for other obvious reasons. We 
> would really like to use sync=true here like everywhere. I'll see what I can 
> do.



--
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-7441) Streaming aggregation error messages could use some improvement

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-7441:
--

Ok, found the problem. The exception is being thrown but not logged. So it 
appears in the test and the browser but not in the log. I'll figure out why.

> Streaming aggregation error messages could use some improvement
> ---
>
> Key: SOLR-7441
> URL: https://issues.apache.org/jira/browse/SOLR-7441
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.1
>Reporter: Erick Erickson
>Assignee: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-7441.patch, SOLR-7441.patch
>
>
> It's harder than it could be to figure out what the error is when using 
> Streaming Aggregation. For instance if you specify an fl parameter for a 
> field that doesn't exist it's hard to figure out that's the cause. This is 
> true even if you look in the Solr logs.
> I'm not quite sure whether it'd be possible to report this at the client 
> level or not, but it seems at least we could repor something more helpful in 
> the Solr logs.



--
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-7441) Streaming aggregation error messages could use some improvement

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-7441:
--

Also I'm assuming you're using the "/export" handler.

> Streaming aggregation error messages could use some improvement
> ---
>
> Key: SOLR-7441
> URL: https://issues.apache.org/jira/browse/SOLR-7441
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.1
>Reporter: Erick Erickson
>Assignee: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-7441.patch, SOLR-7441.patch
>
>
> It's harder than it could be to figure out what the error is when using 
> Streaming Aggregation. For instance if you specify an fl parameter for a 
> field that doesn't exist it's hard to figure out that's the cause. This is 
> true even if you look in the Solr logs.
> I'm not quite sure whether it'd be possible to report this at the client 
> level or not, but it seems at least we could repor something more helpful in 
> the Solr logs.



--
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-7441) Streaming aggregation error messages could use some improvement

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-7441:
--

[~erickerickson], just ran a test case with an incorrect fl and got the error 
below. So I think there is another factor involved when the error doesn't 
appear in the logs. I'll see if I can reproduce the issue. Let me know if you 
can reproduce it.

Throwable #1: org.apache.solr.common.SolrException: undefined field: "blah1"
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([1A2758A869E78AB2:AED7CFC964A88012]:0)
   [junit4]>at 
org.apache.solr.schema.IndexSchema.getField(IndexSchema.java:1223)
   [junit4]>at 
org.apache.solr.response.SortingResponseWriter.getFieldWriters(SortingResponseWriter.java:232)
   [junit4]>at 
org.apache.solr.response.SortingResponseWriter.write(SortingResponseWriter.java:120)
   [junit4]>at 
org.apache.solr.util.TestHarness.query(TestHarness.java:326)
   [junit4]>at 
org.apache.solr.util.TestHarness.query(TestHarness.java:302)
   [junit4]>at 
org.apache.solr.response.TestSortingResponseWriter.testSortingOutput(TestSortingResponseWriter.java:145)
   [junit4]>at java.lang.Thread.run(Thread.java:745)

> Streaming aggregation error messages could use some improvement
> ---
>
> Key: SOLR-7441
> URL: https://issues.apache.org/jira/browse/SOLR-7441
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.1
>Reporter: Erick Erickson
>Assignee: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-7441.patch, SOLR-7441.patch
>
>
> It's harder than it could be to figure out what the error is when using 
> Streaming Aggregation. For instance if you specify an fl parameter for a 
> field that doesn't exist it's hard to figure out that's the cause. This is 
> true even if you look in the Solr logs.
> I'm not quite sure whether it'd be possible to report this at the client 
> level or not, but it seems at least we could repor something more helpful in 
> the Solr logs.



--
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-6068) solr: timing-debug to include lucene-search-time

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar commented on SOLR-6068:
-

Let me know when you have an updated patch..

> solr: timing-debug to include lucene-search-time
> 
>
> Key: SOLR-6068
> URL: https://issues.apache.org/jira/browse/SOLR-6068
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Ramkumar Aiyengar
>
> github pull request with the proposed change to follow.



--
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-6730) select?replicaAffinity=(node|host) and replicaAffinity.hostPriorities support

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar reassigned SOLR-6730:
---

Assignee: Ramkumar Aiyengar

> select?replicaAffinity=(node|host) and replicaAffinity.hostPriorities support
> -
>
> Key: SOLR-6730
> URL: https://issues.apache.org/jira/browse/SOLR-6730
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Ramkumar Aiyengar
>
> If no shards parameter is supplied with a select request then sub-requests 
> will go to a random selection of live solr nodes hosting shards for the 
> collection of interest. All sub-requests must complete before results can be 
> collated i.e. the slowest sub-request determines how fast the search 
> completes.
> Use of optional replicaAffinity can reduce the number of JVMs hit by a given 
> search (the more JVMs are hit, the higher the chance of hitting a garbage 
> collection pause in one of many JVMs). Preferentially directing requests to 
> certain areas of the cloud can also be useful for debugging or when some 
> replicas reside on 'faster' machines.



--
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-6068) solr: timing-debug to include lucene-search-time

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar reassigned SOLR-6068:
---

Assignee: Ramkumar Aiyengar

> solr: timing-debug to include lucene-search-time
> 
>
> Key: SOLR-6068
> URL: https://issues.apache.org/jira/browse/SOLR-6068
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Ramkumar Aiyengar
>
> github pull request with the proposed change to follow.



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

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

Re: [JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 257 - Still Failing

[Steve Rowe]

This is yet another of the SOLR-7429 hydra’s heads.  I’m looking at it.

> On Apr 25, 2015, at 6:21 AM, Michael McCandless  
> wrote:
> 
> Is anyone looking at this?  Should we disable this "sheisty class" in
> Solr's WAR?
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com
> 
> 
> On Fri, Apr 24, 2015 at 7:13 PM, Apache Jenkins Server
>  wrote:
>> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/257/
>> 
>> No tests ran.
>> 
>> Build Log:
>> [...truncated 52433 lines...]
>> prepare-release-no-sign:
>>[mkdir] Created dir: 
>> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist
>> [copy] Copying 446 files to 
>> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene
>> [copy] Copying 245 files to 
>> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr
>>   [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
>>   [smoker] NOTE: output encoding is US-ASCII
>>   [smoker]
>>   [smoker] Load release URL 
>> "file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/"...
>>   [smoker]
>>   [smoker] Test Lucene...
>>   [smoker]   test basics...
>>   [smoker]   get KEYS
>>   [smoker] 0.1 MB in 0.02 sec (8.4 MB/sec)
>>   [smoker]   check changes HTML...
>>   [smoker]   download lucene-5.2.0-src.tgz...
>>   [smoker] 28.2 MB in 0.04 sec (684.8 MB/sec)
>>   [smoker] verify md5/sha1 digests
>>   [smoker]   download lucene-5.2.0.tgz...
>>   [smoker] 64.8 MB in 0.09 sec (687.8 MB/sec)
>>   [smoker] verify md5/sha1 digests
>>   [smoker]   download lucene-5.2.0.zip...
>>   [smoker] 74.6 MB in 0.13 sec (552.3 MB/sec)
>>   [smoker] verify md5/sha1 digests
>>   [smoker]   unpack lucene-5.2.0.tgz...
>>   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>>   [smoker] test demo with 1.7...
>>   [smoker]   got 5777 hits for query "lucene"
>>   [smoker] checkindex with 1.7...
>>   [smoker] check Lucene's javadoc JAR
>>   [smoker]   unpack lucene-5.2.0.zip...
>>   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>>   [smoker] test demo with 1.7...
>>   [smoker]   got 5777 hits for query "lucene"
>>   [smoker] checkindex with 1.7...
>>   [smoker] check Lucene's javadoc JAR
>>   [smoker]   unpack lucene-5.2.0-src.tgz...
>>   [smoker] make sure no JARs/WARs in src dist...
>>   [smoker] run "ant validate"
>>   [smoker] run tests w/ Java 7 and 
>> testArgs='-Dtests.jettyConnector=Socket -Dtests.multiplier=1 
>> -Dtests.slow=false'...
>>   [smoker] test demo with 1.7...
>>   [smoker]   got 208 hits for query "lucene"
>>   [smoker] checkindex with 1.7...
>>   [smoker] generate javadocs w/ Java 7...
>>   [smoker]
>>   [smoker] Crawl/parse...
>>   [smoker]
>>   [smoker] Verify...
>>   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
>>   [smoker] find all past Lucene releases...
>>   [smoker] run TestBackwardsCompatibility..
>>   [smoker] success!
>>   [smoker]
>>   [smoker] Test Solr...
>>   [smoker]   test basics...
>>   [smoker]   get KEYS
>>   [smoker] 0.1 MB in 0.00 sec (68.5 MB/sec)
>>   [smoker]   check changes HTML...
>>   [smoker]   download solr-5.2.0-src.tgz...
>>   [smoker] 36.0 MB in 0.07 sec (485.0 MB/sec)
>>   [smoker] verify md5/sha1 digests
>>   [smoker]   download solr-5.2.0.tgz...
>>   [smoker] 126.4 MB in 0.21 sec (595.5 MB/sec)
>>   [smoker] verify md5/sha1 digests
>>   [smoker]   download solr-5.2.0.zip...
>>   [smoker] 133.0 MB in 0.15 sec (904.3 MB/sec)
>>   [smoker] verify md5/sha1 digests
>>   [smoker]   unpack solr-5.2.0.tgz...
>>   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>>   [smoker] unpack lucene-5.2.0.tgz...
>>   [smoker]   **WARNING**: skipping check of 
>> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.2.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
>>  it has javax.* classes
>>   [smoker]   **WARNING**: skipping check of 
>> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.2.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
>>  it has javax.* classes
>>   [smoker]   **WARNING**: skipping check of 
>> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.2.0/server/lib/ext/javax.servlet-api-3.0.1.jar:
>>  it has javax.* classes
>>   [smoker] verify WAR metadata/contained JAR identity/no javax.* or 
>> java.* classes...
>>   [smoker] unpack lucene-5.2.0.tgz...
>>   [smoker] Traceback (most recent call last):
>>   [smoker]   File 
>> "/usr/home/jenkins/jenkins-

[jira] [Resolved] (SOLR-7081) create/delete/create collection (new test case)

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar resolved SOLR-7081.
-
   Resolution: Fixed
Fix Version/s: 5.2

Thanks Christine..

> create/delete/create collection (new test case)
> ---
>
> Key: SOLR-7081
> URL: https://issues.apache.org/jira/browse/SOLR-7081
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Ramkumar Aiyengar
>Priority: Minor
> Fix For: 5.2
>
>
> Unexpectedly the second collection create fails (saying that the collection 
> already exists) despite the collection delete having apparently succeeded.
> Collection create/delete/create is probably an uncommon operational sequence 
> but perhaps the test failure indicates that something unexpected is happening 
> elsewhere.
> github pull request and test log extracts to follow.



--
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-7081) create/delete/create collection (new test case)

[ASF subversion and git services (JIRA)]

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

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

Commit 1676024 from [~andyetitmoves] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1676024 ]

SOLR-7081: TestMiniSolrCloudCluster.testBasics tidies up after itself, adds 
collection create/delete/create test case.

TestMiniSolrCloudCluster.testBasics now re-creates the server it removed for 
test purposes,
thus restoring the original NUM_SERVERS count. 
TestMiniSolrCloudCluster.testBasics now also deletes
the collection it created for test purposes (this revision adds 
MiniSolrCloudCluster.deleteCollection
and AbstractDistribZkTestBase.waitForCollectionToDisappear methods).

Sometimes TestMiniSolrCloudCluster.testBasics runs its 
create-collection/search-collection/delete-collection
logic twice, thus creating a create/delete/create-collection test case.

> create/delete/create collection (new test case)
> ---
>
> Key: SOLR-7081
> URL: https://issues.apache.org/jira/browse/SOLR-7081
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Ramkumar Aiyengar
>Priority: Minor
>
> Unexpectedly the second collection create fails (saying that the collection 
> already exists) despite the collection delete having apparently succeeded.
> Collection create/delete/create is probably an uncommon operational sequence 
> but perhaps the test failure indicates that something unexpected is happening 
> elsewhere.
> github pull request and test log extracts to follow.



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

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

[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_40) - Build # 4606 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4606/
Java: 32bit/jdk1.8.0_40 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.search.stats.TestDefaultStatsCache.test

Error Message:
Timeout occured while waiting response from server at: 
https://127.0.0.1:51126/l_/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:51126/l_/collection1
at 
__randomizedtesting.SeedInfo.seed([25670BDEF88252D:8A024F67417448D5]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:572)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:174)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:139)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:153)
at 
org.apache.solr.BaseDistributedSearchTestCase.index_specific(BaseDistributedSearchTestCase.java:534)
at 
org.apache.solr.search.stats.TestDefaultStatsCache.test(TestDefaultStatsCache.java:62)
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:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:982)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdap

Re: [CI] Lucene 5x Linux Java8 64 Test Only - Build # 43838 - Failure!

[Michael McCandless]

This was a test bug ... I committed a fix.

Mike McCandless

On Sat, Apr 25, 2015 at 1:50 AM,  wrote:

>   *BUILD FAILURE*
> Build URL
> http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/43838/
> Project:lucene_linux_java8_64_test_only Randomization: 
> JDKEA9,local,heap[743m],-server
> +UseConcMarkSweepGC -UseCompressedOops Date of build:Sat, 25 Apr 2015
> 07:42:29 +0200 Build duration:7 min 53 sec
>  *CHANGES* No Changes
>  *BUILD ARTIFACTS*
>
> checkout/lucene/build/highlighter/test/temp/junit4-J0-20150425_075006_914.events
> 
>
> checkout/lucene/build/highlighter/test/temp/junit4-J1-20150425_075006_914.events
> 
>
> checkout/lucene/build/highlighter/test/temp/junit4-J2-20150425_075006_914.events
> 
>
> checkout/lucene/build/highlighter/test/temp/junit4-J3-20150425_075006_914.events
> 
>
> checkout/lucene/build/highlighter/test/temp/junit4-J4-20150425_075006_914.events
> 
>
> checkout/lucene/build/highlighter/test/temp/junit4-J5-20150425_075006_915.events
> 
>
> checkout/lucene/build/highlighter/test/temp/junit4-J6-20150425_075006_914.events
> 
>
> checkout/lucene/build/highlighter/test/temp/junit4-J7-20150425_075006_915.events
> 
>  *FAILED JUNIT TESTS* Name: org.apache.lucene.search.postingshighlight
> Failed: 1 test(s), Passed: 53 test(s), Skipped: 0 test(s), Total: 54 test(s)
> *Failed:
> org.apache.lucene.search.postingshighlight.TestPostingsHighlighter.testFieldSometimesMissingFromSegment
> *
>  *CONSOLE OUTPUT* [...truncated 9133 lines...] [junit4]  [junit4]
> [junit4] JVM J0: 1.08 .. 6.07 = 4.99s [junit4] JVM J1: 0.84 .. 8.76 =
> 7.92s [junit4] JVM J2: 0.84 .. 5.67 = 4.82s [junit4] JVM J3: 1.08 .. 5.17
> = 4.09s [junit4] JVM J4: 1.08 .. 5.64 = 4.55s [junit4] JVM J5: 1.08 ..
> 5.16 = 4.08s [junit4] JVM J6: 0.84 .. 4.91 = 4.07s [junit4] JVM J7: 1.08
> .. 5.16 = 4.07s [junit4] Execution time total: 8.77 sec. [junit4] Tests
> summary: 22 suites, 251 tests, 1 failure BUILD FAILED 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:466:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:2230:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/module-build.xml:58:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1434:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:991:
> There were test failures: 22 suites, 251 tests, 1 failure Total time: 7
> minutes 42 seconds Build step 'Invoke Ant' marked build as failure Archiving
> artifacts Recording test results [description-setter] Description set:
> JDKEA9,local,heap[743m],-server +UseConcMarkSweepGC -UseCompressedOops Email
> was triggered for: Failure - 1st Trigger Failure - Any was overridden by
> another trigger and will not send an email. Trigger Failure - Still was
> overridden by another trigger and will not send an email. Sending email
> for trigger: Failure - 1st
>

Re: [JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 257 - Still Failing

[Michael McCandless]

Is anyone looking at this?  Should we disable this "sheisty class" in
Solr's WAR?

Mike McCandless

http://blog.mikemccandless.com


On Fri, Apr 24, 2015 at 7:13 PM, Apache Jenkins Server
 wrote:
> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/257/
>
> No tests ran.
>
> Build Log:
> [...truncated 52433 lines...]
> prepare-release-no-sign:
> [mkdir] Created dir: 
> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist
>  [copy] Copying 446 files to 
> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene
>  [copy] Copying 245 files to 
> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr
>[smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
>[smoker] NOTE: output encoding is US-ASCII
>[smoker]
>[smoker] Load release URL 
> "file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/"...
>[smoker]
>[smoker] Test Lucene...
>[smoker]   test basics...
>[smoker]   get KEYS
>[smoker] 0.1 MB in 0.02 sec (8.4 MB/sec)
>[smoker]   check changes HTML...
>[smoker]   download lucene-5.2.0-src.tgz...
>[smoker] 28.2 MB in 0.04 sec (684.8 MB/sec)
>[smoker] verify md5/sha1 digests
>[smoker]   download lucene-5.2.0.tgz...
>[smoker] 64.8 MB in 0.09 sec (687.8 MB/sec)
>[smoker] verify md5/sha1 digests
>[smoker]   download lucene-5.2.0.zip...
>[smoker] 74.6 MB in 0.13 sec (552.3 MB/sec)
>[smoker] verify md5/sha1 digests
>[smoker]   unpack lucene-5.2.0.tgz...
>[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>[smoker] test demo with 1.7...
>[smoker]   got 5777 hits for query "lucene"
>[smoker] checkindex with 1.7...
>[smoker] check Lucene's javadoc JAR
>[smoker]   unpack lucene-5.2.0.zip...
>[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>[smoker] test demo with 1.7...
>[smoker]   got 5777 hits for query "lucene"
>[smoker] checkindex with 1.7...
>[smoker] check Lucene's javadoc JAR
>[smoker]   unpack lucene-5.2.0-src.tgz...
>[smoker] make sure no JARs/WARs in src dist...
>[smoker] run "ant validate"
>[smoker] run tests w/ Java 7 and 
> testArgs='-Dtests.jettyConnector=Socket -Dtests.multiplier=1 
> -Dtests.slow=false'...
>[smoker] test demo with 1.7...
>[smoker]   got 208 hits for query "lucene"
>[smoker] checkindex with 1.7...
>[smoker] generate javadocs w/ Java 7...
>[smoker]
>[smoker] Crawl/parse...
>[smoker]
>[smoker] Verify...
>[smoker]   confirm all releases have coverage in TestBackwardsCompatibility
>[smoker] find all past Lucene releases...
>[smoker] run TestBackwardsCompatibility..
>[smoker] success!
>[smoker]
>[smoker] Test Solr...
>[smoker]   test basics...
>[smoker]   get KEYS
>[smoker] 0.1 MB in 0.00 sec (68.5 MB/sec)
>[smoker]   check changes HTML...
>[smoker]   download solr-5.2.0-src.tgz...
>[smoker] 36.0 MB in 0.07 sec (485.0 MB/sec)
>[smoker] verify md5/sha1 digests
>[smoker]   download solr-5.2.0.tgz...
>[smoker] 126.4 MB in 0.21 sec (595.5 MB/sec)
>[smoker] verify md5/sha1 digests
>[smoker]   download solr-5.2.0.zip...
>[smoker] 133.0 MB in 0.15 sec (904.3 MB/sec)
>[smoker] verify md5/sha1 digests
>[smoker]   unpack solr-5.2.0.tgz...
>[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
>[smoker] unpack lucene-5.2.0.tgz...
>[smoker]   **WARNING**: skipping check of 
> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.2.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
>  it has javax.* classes
>[smoker]   **WARNING**: skipping check of 
> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.2.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
>  it has javax.* classes
>[smoker]   **WARNING**: skipping check of 
> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.2.0/server/lib/ext/javax.servlet-api-3.0.1.jar:
>  it has javax.* classes
>[smoker] verify WAR metadata/contained JAR identity/no javax.* or 
> java.* classes...
>[smoker] unpack lucene-5.2.0.tgz...
>[smoker] Traceback (most recent call last):
>[smoker]   File 
> "/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
>  line 1533, in 
>[smoker] main()
>[smoker]   File 
> "/usr/home/jenkins/jenkins-s

Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b54) - Build # 12442 - Failure!

[Michael McCandless]

I committed a fix.

Mike McCandless

http://blog.mikemccandless.com


On Sat, Apr 25, 2015 at 6:12 AM, Michael McCandless
 wrote:
> New test, I'll dig ...
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Sat, Apr 25, 2015 at 5:18 AM, Policeman Jenkins Server
>  wrote:
>> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12442/
>> Java: 64bit/jdk1.9.0-ea-b54 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC
>>
>> 1 tests failed.
>> FAILED:  
>> org.apache.lucene.search.postingshighlight.TestPostingsHighlighter.testFieldSometimesMissingFromSegment
>>
>> Error Message:
>>
>>
>> Stack Trace:
>> java.lang.AssertionError
>> at 
>> __randomizedtesting.SeedInfo.seed([2763EB5315F0D5DC:36C9088FF5CEEC0F]:0)
>> at org.junit.Assert.fail(Assert.java:92)
>> at org.junit.Assert.assertTrue(Assert.java:43)
>> at org.junit.Assert.assertNull(Assert.java:551)
>> at org.junit.Assert.assertNull(Assert.java:562)
>> at 
>> org.apache.lucene.search.postingshighlight.TestPostingsHighlighter.testFieldSometimesMissingFromSegment(TestPostingsHighlighter.java:1154)
>> 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:502)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
>> at 
>> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>> at 
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>> at 
>> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>> at 
>> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>> at 
>> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>> at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
>> at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
>> at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
>> at 
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>> at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> at 
>> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
>> at 
>> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>> at 
>> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>> at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> at 
>> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
>> at 
>> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>> at 
>> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>> at 
>> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
>> at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
>>

Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b54) - Build # 12442 - Failure!

[Michael McCandless]

New test, I'll dig ...

Mike McCandless

http://blog.mikemccandless.com


On Sat, Apr 25, 2015 at 5:18 AM, Policeman Jenkins Server
 wrote:
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12442/
> Java: 64bit/jdk1.9.0-ea-b54 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC
>
> 1 tests failed.
> FAILED:  
> org.apache.lucene.search.postingshighlight.TestPostingsHighlighter.testFieldSometimesMissingFromSegment
>
> Error Message:
>
>
> Stack Trace:
> java.lang.AssertionError
> at 
> __randomizedtesting.SeedInfo.seed([2763EB5315F0D5DC:36C9088FF5CEEC0F]:0)
> at org.junit.Assert.fail(Assert.java:92)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertNull(Assert.java:551)
> at org.junit.Assert.assertNull(Assert.java:562)
> at 
> org.apache.lucene.search.postingshighlight.TestPostingsHighlighter.testFieldSometimesMissingFromSegment(TestPostingsHighlighter.java:1154)
> 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:502)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
> at java.lang.Thread.run(Thread.java:745)
>
>
>
>
> Build Log:
> [...truncated 6846 lines...]
>[junit4] Suite: 
> org.apache.lucene.search.postingshighlight.TestPostingsHighlighter
>[junit4]   2> NOTE: reproduce with: ant tes

[jira] [Resolved] (LUCENE-5669) Make it easier to index a full binary term

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-5669.

Resolution: Duplicate

This was fixed with LUCENE-5989

> Make it easier to index a full binary term
> --
>
> Key: LUCENE-5669
> URL: https://issues.apache.org/jira/browse/LUCENE-5669
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
> Fix For: Trunk, 4.9
>
>
> When I ran performance tests for different UUID fields for 
> http://blog.mikemccandless.com/2014/05/choosing-fast-unique-identifier-uuid.html
>  I found that full binary term, i.e. base / radix 256 using all 256 values of 
> each byte, was typically faster than the "default" base 16/36/etc. encoding 
> for UUIDs.
> But in Lucene today it's a hassle to index a binary term (I had to go poach 
> BinaryTokenStream from tests).
> I think we should make this easier so apps are encouraged to use it for their 
> ID-like fields.
> Maybe we add an indexable option to BinaryField?



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

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

[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b54) - Build # 12271 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12271/
Java: 32bit/jdk1.9.0-ea-b54 -client -XX:+UseConcMarkSweepGC

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

Error Message:
There were too many update fails (31 > 20) - we expect it can happen, but 
shouldn't easily

Stack Trace:
java.lang.AssertionError: There were too many update fails (31 > 20) - we 
expect it can happen, but shouldn't easily
at 
__randomizedtesting.SeedInfo.seed([525F488434F9F656:DA0B775E9A059BAE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:230)
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:502)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:

[jira] [Commented] (SOLR-7382) SOLR-7241 introduced a partials directory in the root checkout dir.

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-7382:
-

Any news on this? "partials" folder is still there! If nobody objects, I will 
remove it later this day.


> SOLR-7241 introduced a partials directory in the root checkout dir.
> ---
>
> Key: SOLR-7382
> URL: https://issues.apache.org/jira/browse/SOLR-7382
> Project: Solr
>  Issue Type: Bug
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>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

RE: partials/ folder in checkout

[Uwe Schindler]

Hi,

any news on this. "partials" folder is still there! If nobody objects, I will 
remove it later this day.

Uwe

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


> -Original Message-
> From: Erick Erickson [mailto:erickerick...@gmail.com]
> Sent: Sunday, April 12, 2015 10:56 PM
> To: dev@lucene.apache.org
> Subject: Re: partials/ folder in checkout
> 
> I'm tracking that, see SOLR-7382. I suspect it's an accident, will confirm and
> remove probably tomorrow unless it's causing people grief.
> 
> On Sun, Apr 12, 2015 at 11:19 AM, Uwe Schindler  wrote:
> > Thanks. I just noticed while checking with preview build of
> > forbiddenapis
> > 1.8 :)
> >
> > Uwe
> >
> >
> > Am 12. April 2015 20:11:17 MESZ, schrieb Shalin Shekhar Mangar
> > :
> >>
> >> Yes, I noticed that too and I commented on the original issue. See
> >> https://issues.apache.org/jira/browse/SOLR-7241?page=com.atlassian.ji
> >> ra.plugin.system.issuetabpanels:comment-
> tabpanel&focusedCommentId=144
> >> 90844#comment-14490844
> >>
> >>
> >> On Sun, Apr 12, 2015 at 11:32 PM, Uwe Schindler 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Trunk and branch_5x now contain a strange partials/ folder in the
> >>> root of the checkout. Is this intended. To me this looks like a
> >>> relict which was accidentally committed.
> >>>
> >>> If this is true, please remove!
> >>>
> >>> Uwe
> >>>
> >>> -
> >>> Uwe Schindler
> >>> H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de
> >>> eMail: u...@thetaphi.de
> >>>
> >>>
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Shalin Shekhar Mangar.
> >
> >
> > --
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, 28213 Bremen
> > http://www.thetaphi.de
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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

Re: 16K threads used up, Solr 4.10 doing nothing.

[Dmitry Kan]

Hi Erick,

Do you know, whether the client used facet.threads, even once?

There's a bug in solr with threaded faceting, that makes use of unlimited
amount of threads.

Regards,
Dmitry
On 24 Apr 2015 3:17 am, "Erick Erickson"  wrote:

> A client had a Solr instance doing absolutely nothing for a month.
> Literally a test system that was idle. When they tried to finally do
> something, they couldn't. That Solr process had over 16K threads
> operating. No indexing, no querying, was going on, nada.
>
> They investigated and found that the Solr couldn't connect to
> Zookeeper and had a zillion threads (well, actually about 16K which
> was their limit) with the stack trace at the end.
>
> Admittedly the client had a weird situation where Solr couldn't talk
> to Zookeeper, and admittedly Solr can't do much if it can't talk to
> ZK.
>
> Even so this seems odd. I'm also a bit worried that if they fix the
> reason Solr couldn't talk to ZK (maybe it's a firewall issue? plug the
> cable back in?) that when all those threads suddenly get to do their
> thing what will happen? Not to mention any effects on other processes.
>
> Anyway, if this is worth a JIRA I can create one if there aren't any
> already.
>
> Solr 4.10
>
> Here's the stack trace:
>
> "main-EventThread" daemon prio=10 tid=0x0a38d000 nid=0xeb51 in
> Object.wait() [0x7e8c15c89000]
>
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
>at java.lang.Object.wait(Native Method)
>at
> org.apache.solr.common.cloud.ConnectionManager.waitForConnected(ConnectionManager.java:215)
> - locked <0x0003c5306fc0> (a
> org.apache.solr.common.cloud.ConnectionManager)
> at
> org.apache.solr.common.cloud.ConnectionManager$1.update(ConnectionManager.java:138)
> at
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:56)
> at
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
>
> Erick
>
> -
> 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.9.0-ea-b54) - Build # 12442 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12442/
Java: 64bit/jdk1.9.0-ea-b54 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.lucene.search.postingshighlight.TestPostingsHighlighter.testFieldSometimesMissingFromSegment

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([2763EB5315F0D5DC:36C9088FF5CEEC0F]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.junit.Assert.assertNull(Assert.java:562)
at 
org.apache.lucene.search.postingshighlight.TestPostingsHighlighter.testFieldSometimesMissingFromSegment(TestPostingsHighlighter.java:1154)
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:502)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 6846 lines...]
   [junit4] Suite: 
org.apache.lucene.search.postingshighlight.TestPostingsHighlighter
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestPostingsHighlighter 
-Dtests.method=testFieldSometimesMissingFromSegment 
-Dtests.seed=2763EB5315F0D5DC -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=zh_SG_#Hans -Dtests.timezone=Asia/Kuwait -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.06s J2 | 
TestPostingsHighlighter.tes

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.TestHighlightDedupGrouping.test

Error Message:
Timeout occured while waiting response from server at: 
https://127.0.0.1:64897/dbpoe/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:64897/dbpoe/collection1
at 
__randomizedtesting.SeedInfo.seed([79A1115B71854DEA:F1F52E81DF792012]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:570)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:174)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:139)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:153)
at 
org.apache.solr.TestHighlightDedupGrouping.addDoc(TestHighlightDedupGrouping.java:122)
at 
org.apache.solr.TestHighlightDedupGrouping.randomizedTest(TestHighlightDedupGrouping.java:96)
at 
org.apache.solr.TestHighlightDedupGrouping.test(TestHighlightDedupGrouping.java:42)
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:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.eva

[jira] [Commented] (SOLR-7461) StatsComponent, calcdistinct, ability to disable distinctValues while keeping countDistinct

[James Andres (JIRA)]

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

James Andres commented on SOLR-7461:


Thanks for replying so quickly [~hossman].

What you say makes total sense. Calcdistinct is not very friendly to memory or 
CPU on our Solr cluster, and we are aware of why! :)

Unfortunately, for me, being able to get exact (or very nearly exact) distinct 
counts is important for the application I'm building (it's an analytics / stats 
tool so correct numbers are a must have feature). The trouble is I rarely need 
to know what the unique values actually are.

The specific itch I'm hoping to scratch is to avoid the 10MB to 30MB  of 
distinctValues coming over the wire to the app servers which my Python app 
needs to parse then immediately discard. Without distinctValues my JSON 
responses drop to a few kilobytes in size.

Regarding the hyperloglog approach:
- This is awesome. I can definitely use this :D
- Can you speculate on how the precision will be controlled? Will it be in the 
query or in solrconfig.xml or both?
- Can I crank the precision way up such that when dealing with hundreds of 
millions of unique items it will be nearly exact counts (eg: off by > 100)?

> StatsComponent, calcdistinct, ability to disable distinctValues while keeping 
> countDistinct
> ---
>
> Key: SOLR-7461
> URL: https://issues.apache.org/jira/browse/SOLR-7461
> Project: Solr
>  Issue Type: Improvement
>Reporter: James Andres
>  Labels: statscomponent
>
> When using calcdistinct with large amounts of data the distinctValues field 
> can be extremely large. In cases where the countDistinct is only required it 
> would be helpful if the server did not return distinctValues in the response.
> I'm no expert, but here are some ideas for how the syntax could look.
> {code}
> # Both countDistinct and distinctValues are returned, along with all other 
> stats
> stats.calcdistinct=true&stats.field=myfield
> # Only countDistinct and distinctValues are returned
> stats.calcdistinct=true&stats.field={!countDistinct=true 
> distinctValues=true}myfield
> # Only countDistinct is returned
> stats.calcdistinct=true&stats.field={!countDistinct=true}myfield
> # Only distinctValues is returned
> stats.calcdistinct=true&stats.field={!distinctValues=true}myfield
> {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-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2222 - Still Failing!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.client.solrj.impl.CloudSolrClientTest.test

Error Message:
Error from server at http://127.0.0.1:63376/i_/q/checkStateVerCol: no servers 
hosting shard: 

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:63376/i_/q/checkStateVerCol: no servers hosting 
shard: 
at 
__randomizedtesting.SeedInfo.seed([2E079705C0EFF3BA:A653A8DF6E139E42]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.stateVersionParamTest(CloudSolrClientTest.java:554)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementA