[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_60) - Build # 14174 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14174/
Java: 32bit/jdk1.8.0_60 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
Delete action failed!

Stack Trace:
java.lang.AssertionError: Delete action failed!
at 
__randomizedtesting.SeedInfo.seed([A20B33D0D1069E7E:B16801BFE06927D8]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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 

[jira] [Reopened] (SOLR-7792) Upgrade morfologik-stemming to version 1.10.0

[Dawid Weiss (JIRA)]

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

Dawid Weiss reopened SOLR-7792:
---

> Upgrade morfologik-stemming to version 1.10.0
> -
>
> Key: SOLR-7792
> URL: https://issues.apache.org/jira/browse/SOLR-7792
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 5.4, Trunk
>
>




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

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

[jira] [Reopened] (SOLR-7790) Update Carrot2 clustering contrib to version 3.10.4

[Dawid Weiss (JIRA)]

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

Dawid Weiss reopened SOLR-7790:
---

> Update Carrot2 clustering contrib to version 3.10.4
> ---
>
> Key: SOLR-7790
> URL: https://issues.apache.org/jira/browse/SOLR-7790
> Project: Solr
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-7790.patch, SOLR-7790.patch
>
>
> This issue brings the clustering extension up to date and also involves 
> upgrading a few other libraries (see sub-tasks or linked issues).



--
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-7792) Upgrade morfologik-stemming to version 1.10.0

[Dawid Weiss (JIRA)]

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

Dawid Weiss resolved SOLR-7792.
---
Resolution: Duplicate

> Upgrade morfologik-stemming to version 1.10.0
> -
>
> Key: SOLR-7792
> URL: https://issues.apache.org/jira/browse/SOLR-7792
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 5.4, Trunk
>
>




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

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

[jira] [Updated] (SOLR-7790) Update Carrot2 clustering contrib to version 3.10.4

[Dawid Weiss (JIRA)]

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

Dawid Weiss updated SOLR-7790:
--
Summary: Update Carrot2 clustering contrib to version 3.10.4  (was: Update 
Carrot2 clustering contrib to version 3.10.3)

> Update Carrot2 clustering contrib to version 3.10.4
> ---
>
> Key: SOLR-7790
> URL: https://issues.apache.org/jira/browse/SOLR-7790
> Project: Solr
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-7790.patch, SOLR-7790.patch
>
>
> This issue brings the clustering extension up to date and also involves 
> upgrading a few other libraries (see sub-tasks or linked issues).



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

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

[jira] [Resolved] (LUCENE-6823) Remove use of System.currentTimeMillis() from LocalReplicator

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-6823.

   Resolution: Fixed
Fix Version/s: 5.4
   Trunk

Thanks [~ichattopadhyaya]!

> Remove use of System.currentTimeMillis() from LocalReplicator
> -
>
> Key: LUCENE-6823
> URL: https://issues.apache.org/jira/browse/LUCENE-6823
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Priority: Minor
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6823.patch, LUCENE-6823.patch
>
>
> LocalReplicator uses System.currentTimeMillis() for session expiry, which is 
> not guaranteed monotonic.



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

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

[jira] [Commented] (LUCENE-6301) Deprecate Filter

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6301:
--

I plan to commit next week if there are no objections.

> Deprecate Filter
> 
>
> Key: LUCENE-6301
> URL: https://issues.apache.org/jira/browse/LUCENE-6301
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Fix For: 5.2, Trunk
>
> Attachments: LUCENE-6301.patch, LUCENE-6301.patch
>
>
> It will still take time to completely remove Filter, but I think we should 
> start deprecating it now to state our intention and encourage users to move 
> to queries as soon as possible?



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

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

[jira] [Commented] (LUCENE-6823) Remove use of System.currentTimeMillis() from LocalReplicator

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6823:


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

> Remove use of System.currentTimeMillis() from LocalReplicator
> -
>
> Key: LUCENE-6823
> URL: https://issues.apache.org/jira/browse/LUCENE-6823
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: LUCENE-6823.patch, LUCENE-6823.patch
>
>
> LocalReplicator uses System.currentTimeMillis() for session expiry, which is 
> not guaranteed monotonic.



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

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

[jira] [Commented] (LUCENE-6823) Remove use of System.currentTimeMillis() from LocalReplicator

[ASF subversion and git services (JIRA)]

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

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

Commit 1707684 from [~mikemccand] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1707684 ]

LUCENE-6823: use System.nanoTime for expiration in LocalReplicator

> Remove use of System.currentTimeMillis() from LocalReplicator
> -
>
> Key: LUCENE-6823
> URL: https://issues.apache.org/jira/browse/LUCENE-6823
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: LUCENE-6823.patch, LUCENE-6823.patch
>
>
> LocalReplicator uses System.currentTimeMillis() for session expiry, which is 
> not guaranteed monotonic.



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

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

[JENKINS-EA] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b83) - Build # 14175 - Still Failing!

[Policeman Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 245 lines...]
[javac] Compiling 727 source files to 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/classes/java
[javac] 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/core/src/java/org/apache/lucene/search/Query.java:121:
 error: ';' expected
[javac] return Float.floatToIntBits(boost) == 
Float.floatToIntBits(other.boost)
[javac] 
   ^
[javac] 1 error

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:785: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:729: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:59: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build.xml:50: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:526: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:1964: 
Compile failed; see the compiler error output for details.

Total time: 2 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
ERROR: Publisher 'Publish JUnit test result report' failed: No test report 
files were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
Delete action failed!

Stack Trace:
java.lang.AssertionError: Delete action failed!
at 
__randomizedtesting.SeedInfo.seed([D7A7192CD687DCD1:C4C42B43E7E86577]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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 

[jira] [Updated] (LUCENE-6834) Remove BoostQuery.toString()'s hack with parenthesis

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-6834:
-
Attachment: LUCENE-6834.patch

Here is a patch. I'll commit soon if there are no objections.

> Remove BoostQuery.toString()'s hack with parenthesis
> 
>
> Key: LUCENE-6834
> URL: https://issues.apache.org/jira/browse/LUCENE-6834
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 6.0
>
> Attachments: LUCENE-6834.patch
>
>
> This hack was added in order not to break the string representation of our 
> queries in 5.x. However I don't think we should have it in trunk.



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

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

Early Access build 83 for JDK 9 and JDK 9 with Project Jigsaw are available for download.

[Rory O'Donnell]

Hi Uwe & Dawid,

JDK 9 with Project Jigsaw Early Access build b83 is available for 
download at jdk9.java.net/jigsaw .


Notable changes:

 * The -Xoverride option has been extended and renamed to -Xpatch, and
   the -XaddReads option has been restored [1] (changesets
   04dd0430530e, 095fc622bf01).
 * ClassLoader::getPackage now works as it did previously, walking the
   class-loader hierarchy in order to find Package objects, which
   enables NetBeans to start up [2] (5805781b9370).
 * Class::getResource will now return a URL to a resource in a module,
   when invoked from code within that module (0fbe4c72638a).
 * The big module-summary table has been improved, and will now be
   posted with each build [3] (e922b207c170).


JDK 9 Early Access build b83 is available for download 
 , summary of  changes are listed here 
.


 * Request for G1 GC Feedback at wiki -
   https://wiki.openjdk.java.net/display/HotSpot/G1GC+Feedback
 * This wiki-page aims to outline the basic JVM parameters switching to
   G1GC, and how you can help collecting data comparing the G1GC and
   Parallel GC.

Rgds, Rory

[1]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-September/004740.html
[2]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-September/004730.html
[3]http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.html


--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

RE: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b83) - Build # 14463 - Still Failing!

[Uwe Schindler]

This seems to be a bug in JDK 9 build 83'c Javac. Looks like this was caused by 
one of those issues:

 

http://hg.openjdk.java.net/jdk9/jdk9/langtools


Changeset

Bug ID

Synopsis


8fa8045bbd4e  

8077306  

Recursive implementation of List.map leads to stack overflow


286fc9270404  

8078093  

Severe compiler performance regression Java 7 to 8 for nested method invocations

 

I will contact them through the mailing lists.

 

Uwe

 

-

Uwe Schindler

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

http://www.thetaphi.de

eMail: u...@thetaphi.de

 

 

> -Original Message-

> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]

> Sent: Friday, October 09, 2015 10:08 AM

> To: dev@lucene.apache.org

> Subject: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b83) - Build

> # 14463 - Still Failing!

> Importance: Low

> 

> Build:   
> http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14463/

> Java: 64bit/jdk1.9.0-ea-b83 -XX:+UseCompressedOops -XX:+UseG1GC

> 

> All tests passed

> 

> Build Log:

> [...truncated 8520 lines...]

> [javac] Compiling 874 source files to /home/jenkins/workspace/Lucene-

> Solr-trunk-Linux/solr/build/solr-core/classes/java

> [javac] warning: [options] bootstrap class path not set in conjunction 
> with -

> source 1.8

> [javac] /home/jenkins/workspace/Lucene-Solr-trunk-

> Linux/solr/core/src/java/org/apache/solr/core/ImplicitPlugins.java:102:

> error: reference to NamedList is ambiguous

> [javac] return new PluginInfo(SolrRequestHandler.TYPE, m, new

> NamedList<>(singletonMap(DEFAULTS, new NamedList(defaults))),null);

> [javac]   ^

> [javac]   both constructor NamedList(Entry[]) in

> NamedList and constructor NamedList(Map) in

> NamedList match

> [javac]   where T is a type-variable:

> [javac] T extends Object declared in class NamedList

> [javac] /home/jenkins/workspace/Lucene-Solr-trunk-

> Linux/solr/core/src/java/org/apache/solr/core/ImplicitPlugins.java:102:

> error: incompatible types: cannot infer type arguments for NamedList<>

> [javac] return new PluginInfo(SolrRequestHandler.TYPE, m, new

> NamedList<>(singletonMap(DEFAULTS, new NamedList(defaults))),null);

> [javac]   
>  ^

> [javac] reason: no instance(s) of type variable(s) K,V exist so that

> Map conforms to Entry[]

> [javac]   where K,V,T are type-variables:

> [javac] K extends Object declared in method singletonMap(K,V)

> [javac] V extends Object declared in method singletonMap(K,V)

> [javac] T extends Object declared in class NamedList

> [javac] Note: Some input files use or override a deprecated API.

> [javac] Note: Recompile with -Xlint:deprecation for details.

> [javac] Note: Some input files use unchecked or unsafe operations.

> [javac] Note: Recompile with -Xlint:unchecked for details.

> [javac] Note: Some messages have been simplified; recompile with -

> Xdiags:verbose to get full output

> [javac] 2 errors

> 

> [...truncated 1 lines...]

> BUILD FAILED

> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:775: The

> following error occurred while executing this line:

> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:719: The

> following error occurred while executing this line:

> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:59: The

> following error occurred while executing this line:

> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:233: The

> following error occurred while executing this line:

> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-

> build.xml:516: The following error occurred while executing this line:

> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-

> build.xml:466: The following error occurred while executing this line:

> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-

> build.xml:379: The following error occurred while executing this line:

> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-

> build.xml:509: The following error occurred while executing this line:

> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-

> build.xml:1944: Compile failed; see the compiler error output for details.

> 

> Total time: 18 minutes 54 seconds

> Build step 'Invoke Ant' marked build as failure Archiving artifacts

> [WARNINGS] Skipping publisher since build result is FAILURE Recording test

> results Email 

[jira] [Commented] (SOLR-7790) Update Carrot2 clustering contrib to version 3.10.4

[ASF subversion and git services (JIRA)]

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

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

Commit 1707680 from [~dawidweiss] in branch 'dev/trunk'
[ https://svn.apache.org/r1707680 ]

SOLR-7790: upgrade to C2 3.10.4

> Update Carrot2 clustering contrib to version 3.10.4
> ---
>
> Key: SOLR-7790
> URL: https://issues.apache.org/jira/browse/SOLR-7790
> Project: Solr
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-7790.patch, SOLR-7790.patch
>
>
> This issue brings the clustering extension up to date and also involves 
> upgrading a few other libraries (see sub-tasks or linked issues).



--
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-7790) Update Carrot2 clustering contrib to version 3.10.4

[ASF subversion and git services (JIRA)]

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

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

Commit 1707682 from [~dawidweiss] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1707682 ]

SOLR-7790: upgrade to C2 3.10.4

> Update Carrot2 clustering contrib to version 3.10.4
> ---
>
> Key: SOLR-7790
> URL: https://issues.apache.org/jira/browse/SOLR-7790
> Project: Solr
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-7790.patch, SOLR-7790.patch
>
>
> This issue brings the clustering extension up to date and also involves 
> upgrading a few other libraries (see sub-tasks or linked issues).



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

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

[jira] [Commented] (LUCENE-6467) Simplify Query.equals()

[ASF subversion and git services (JIRA)]

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

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

Commit 1707685 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1707685 ]

LUCENE-6467: Simplify Query.equals.

> Simplify Query.equals()
> ---
>
> Key: LUCENE-6467
> URL: https://issues.apache.org/jira/browse/LUCENE-6467
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-6474.patch
>
>
> Remove this == other test in Query.equals().



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

[Policeman Jenkins Server]

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

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

Error Message:
List size mismatch @ spellcheck/suggestions

Stack Trace:
java.lang.RuntimeException: List size mismatch @ spellcheck/suggestions
at 
__randomizedtesting.SeedInfo.seed([89D6A1E827ED553B:1829E32891138C3]:0)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:853)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:800)
at 
org.apache.solr.handler.component.SpellCheckComponentTest.test(SpellCheckComponentTest.java:96)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 10354 lines...]
   [junit4] Suite: org.apache.solr.handler.component.SpellCheckComponentTest
   [junit4]   2> Creating dataDir: 

[jira] [Resolved] (SOLR-7790) Update Carrot2 clustering contrib to version 3.10.4

[Dawid Weiss (JIRA)]

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

Dawid Weiss resolved SOLR-7790.
---
Resolution: Fixed

> Update Carrot2 clustering contrib to version 3.10.4
> ---
>
> Key: SOLR-7790
> URL: https://issues.apache.org/jira/browse/SOLR-7790
> Project: Solr
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-7790.patch, SOLR-7790.patch
>
>
> This issue brings the clustering extension up to date and also involves 
> upgrading a few other libraries (see sub-tasks or linked issues).



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

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

[jira] [Commented] (LUCENE-6823) Remove use of System.currentTimeMillis() from LocalReplicator

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-6823: use System.nanoTime for expiration in LocalReplicator

> Remove use of System.currentTimeMillis() from LocalReplicator
> -
>
> Key: LUCENE-6823
> URL: https://issues.apache.org/jira/browse/LUCENE-6823
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: LUCENE-6823.patch, LUCENE-6823.patch
>
>
> LocalReplicator uses System.currentTimeMillis() for session expiry, which is 
> not guaranteed monotonic.



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

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

[jira] [Resolved] (LUCENE-6467) Simplify Query.equals()

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-6467.
--
   Resolution: Fixed
 Assignee: Adrien Grand
Fix Version/s: 5.4

Committed.

> Simplify Query.equals()
> ---
>
> Key: LUCENE-6467
> URL: https://issues.apache.org/jira/browse/LUCENE-6467
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Paul Elschot
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6474.patch
>
>
> Remove this == other test in Query.equals().



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

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

[jira] [Commented] (LUCENE-6467) Simplify Query.equals()

[ASF subversion and git services (JIRA)]

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

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

Commit 1707686 from [~jpountz] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1707686 ]

LUCENE-6467: Simplify Query.equals.

> Simplify Query.equals()
> ---
>
> Key: LUCENE-6467
> URL: https://issues.apache.org/jira/browse/LUCENE-6467
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Paul Elschot
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6474.patch
>
>
> Remove this == other test in Query.equals().



--
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-8113) Accept replacement strings in CloneFieldUpdateProcessorFactory

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-8113:


Thanks for the review. You make some good points. I'd probably never want to 
ask the user to repeat patterns that had to match (or want to have to write 
validation around that)... nobody will want to type the regex twice, it could 
only lead to a mistake. Maybe it's as simple as using "replacement" rather than 
dest, and documenting/validating that only one or the other should be supplied. 
If neither is supplied default to ^(.*)$ for the fieldRegex? This results in 
something like:

{code}

  
solr.StrField
  
  $1_t 
{code}

for your first example. In the event they do want to specify a particular 
regex...
 
{code}

  
solr.StrField
^(.*)_s$
  
  $1_t 
{code}

and thus your second example (with no string type) looks like this:

{code}

  
^(.*)_s$
  
  $1_t
{code}

This also seems to avoid the user needing to think about whether or not they 
should use $0 or $1. (except in some sort of funky exotic cases where they 
might be using both $0 and $1, $2, etc... which will involve them supplying a 
pattern anyway and should still work). 


> Accept replacement strings in CloneFieldUpdateProcessorFactory
> --
>
> Key: SOLR-8113
> URL: https://issues.apache.org/jira/browse/SOLR-8113
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 5.3
>Reporter: Gus Heck
> Attachments: SOLR-8113.patch
>
>
> Presently CloneFieldUpdateProcessorFactory accepts regular expressions to 
> select source fields, which mirrors wildcards in the source for copyField in 
> the schema. This patch adds a counterpart to copyField's wildcards in the 
> dest attribute by interpreting the dest parameter as a regex replacement 
> string.



--
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-8152) Overseer Task Processor/Queue can miss responses, leading to timeouts

[Gregory Chanan (JIRA)]

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

Gregory Chanan commented on SOLR-8152:
--

There are a few ways to solve this, the most straightforward of which appears 
to be:
1) Create the response node first using SEQUENTIAL (to generate the path to the 
request node)
2) Watch the response node, so we can't possible miss the response (because the 
request node isn't even created yet)
3) Create the request mode

At this point, before we wait, we check that the watch didn't already fire 
(otherwise we will wait unnecessarily).

> Overseer Task Processor/Queue can miss responses, leading to timeouts
> -
>
> Key: SOLR-8152
> URL: https://issues.apache.org/jira/browse/SOLR-8152
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>
> I noticed some jenkins reports of timeouts in the 
> TestConfigSetsAPIExclusivityTest, which seemed strange given the amount of 
> work to be done is small and the timeout generous at 300 seconds.
> I added some statistics gathering and started beasting the test and sure 
> enough, some tests reported tasks taking slightly more than 300 seconds, 
> while most tests ran with a maximum task run of less than a second.  This 
> suggested something was hanging until the timeout.
> Some investigation lead to this code:
> https://github.com/apache/lucene-solr/blob/80a73535b20debb1717c6f7f11e08fc311833c88/solr/core/src/java/org/apache/solr/cloud/OverseerTaskQueue.java#L179-L194
> There appears to be a few issues here:
> {code}
>  String path = createData(dir + "/" + PREFIX, data,
>   CreateMode.PERSISTENT_SEQUENTIAL);
>   String watchID = createData(
>   dir + "/" + response_prefix + path.substring(path.lastIndexOf("-") 
> + 1),
>   null, CreateMode.EPHEMERAL);
>   Object lock = new Object();
>   LatchWatcher watcher = new LatchWatcher(lock);
>   synchronized (lock) {
> if (zookeeper.exists(watchID, watcher, true) != null) {
>   watcher.await(timeout);
> }
>   }
> {code}
> For one, the request object is created before the response object.  If the 
> request is quickly picked up and processed, two things can happen:
> 1) The response is written before the watch is set, which means we wait until 
> the timeout even though the response is ready.  This will still pass the test 
> because the response is available, the client will just wait needlessly.
> 2) The response is attempted to be written before the response node is even 
> created.  The fact that the response node doesn't exist is ignored:
> https://github.com/apache/lucene-solr/blob/80a73535b20debb1717c6f7f11e08fc311833c88/solr/core/src/java/org/apache/solr/cloud/OverseerTaskQueue.java#L92-L94
> In this case, the task is processed but the client will actually see a 
> failure because there is no response.



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

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

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 15364 lines...]
BUILD FAILED
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/build.xml:775: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/build.xml:719: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/build.xml:59: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/build.xml:253: 
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/common-build.xml:457:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/common-build.xml:516:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/contrib/map-reduce/build.xml:65:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/contrib/morphlines-core/build.xml:98:
 impossible to resolve dependencies:
resolve failed - see output for details

Total time: 99 minutes 22 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 15698 lines...]
BUILD FAILED
/export/home/jenkins/workspace/Lucene-Solr-5.x-Solaris/build.xml:785: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-5.x-Solaris/build.xml:729: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-5.x-Solaris/build.xml:59: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-5.x-Solaris/solr/build.xml:253: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-5.x-Solaris/solr/common-build.xml:467:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-5.x-Solaris/solr/common-build.xml:526:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-5.x-Solaris/solr/contrib/map-reduce/build.xml:65:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-5.x-Solaris/solr/contrib/morphlines-core/build.xml:98:
 impossible to resolve dependencies:
resolve failed - see output for details

Total time: 104 minutes 5 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b83) - Build # 14472 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14472/
Java: 64bit/jdk1.9.0-ea-b83 -XX:-UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 8516 lines...]
[javac] Compiling 879 source files to 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/classes/java
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.8
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/core/ImplicitPlugins.java:102:
 error: reference to NamedList is ambiguous
[javac] return new PluginInfo(SolrRequestHandler.TYPE, m, new 
NamedList<>(singletonMap(DEFAULTS, new NamedList(defaults))),null);
[javac]   ^
[javac]   both constructor NamedList(Entry[]) in 
NamedList and constructor NamedList(Map) in NamedList 
match
[javac]   where T is a type-variable:
[javac] T extends Object declared in class NamedList
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/core/ImplicitPlugins.java:102:
 error: incompatible types: cannot infer type arguments for NamedList<>
[javac] return new PluginInfo(SolrRequestHandler.TYPE, m, new 
NamedList<>(singletonMap(DEFAULTS, new NamedList(defaults))),null);
[javac]^
[javac] reason: no instance(s) of type variable(s) K,V exist so that 
Map conforms to Entry[]
[javac]   where K,V,T are type-variables:
[javac] K extends Object declared in method singletonMap(K,V)
[javac] V extends Object declared in method singletonMap(K,V)
[javac] T extends Object declared in class NamedList
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] Note: Some messages have been simplified; recompile with 
-Xdiags:verbose to get full output
[javac] 2 errors

[...truncated 1 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:719: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:59: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:233: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:516: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:466: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:379: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:509: 
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1944: 
Compile failed; see the compiler error output for details.

Total time: 18 minutes 45 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14473/
Java: 64bit/jdk1.8.0_60 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
Delete action failed!

Stack Trace:
java.lang.AssertionError: Delete action failed!
at 
__randomizedtesting.SeedInfo.seed([E1B160DA64E3DED5:F2D252B5558C6773]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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 

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

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
Delete action failed!

Stack Trace:
java.lang.AssertionError: Delete action failed!
at 
__randomizedtesting.SeedInfo.seed([FD8F3F9C919320A6:EEEC0DF3A0FC9900]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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 

[jira] [Created] (SOLR-8152) Overseer Task Processor/Queue can miss responses, leading to timeouts

[Gregory Chanan (JIRA)]

Gregory Chanan created SOLR-8152:


 Summary: Overseer Task Processor/Queue can miss responses, leading 
to timeouts
 Key: SOLR-8152
 URL: https://issues.apache.org/jira/browse/SOLR-8152
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Gregory Chanan
Assignee: Gregory Chanan


I noticed some jenkins reports of timeouts in the 
TestConfigSetsAPIExclusivityTest, which seemed strange given the amount of work 
to be done is small and the timeout generous at 300 seconds.

I added some statistics gathering and started beasting the test and sure 
enough, some tests reported tasks taking slightly more than 300 seconds, while 
most tests ran with a maximum task run of less than a second.  This suggested 
something was hanging until the timeout.

Some investigation lead to this code:
https://github.com/apache/lucene-solr/blob/80a73535b20debb1717c6f7f11e08fc311833c88/solr/core/src/java/org/apache/solr/cloud/OverseerTaskQueue.java#L179-L194

There appears to be a few issues here:
{code}
 String path = createData(dir + "/" + PREFIX, data,
  CreateMode.PERSISTENT_SEQUENTIAL);
  String watchID = createData(
  dir + "/" + response_prefix + path.substring(path.lastIndexOf("-") + 
1),
  null, CreateMode.EPHEMERAL);

  Object lock = new Object();
  LatchWatcher watcher = new LatchWatcher(lock);
  synchronized (lock) {
if (zookeeper.exists(watchID, watcher, true) != null) {
  watcher.await(timeout);
}
  }
{code}

For one, the request object is created before the response object.  If the 
request is quickly picked up and processed, two things can happen:
1) The response is written before the watch is set, which means we wait until 
the timeout even though the response is ready.  This will still pass the test 
because the response is available, the client will just wait needlessly.
2) The response is attempted to be written before the response node is even 
created.  The fact that the response node doesn't exist is ignored:
https://github.com/apache/lucene-solr/blob/80a73535b20debb1717c6f7f11e08fc311833c88/solr/core/src/java/org/apache/solr/cloud/OverseerTaskQueue.java#L92-L94
In this case, the task is processed but the client will actually see a failure 
because there is no response.



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

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

[jira] [Updated] (SOLR-8152) Overseer Task Processor/Queue can miss responses, leading to timeouts

[Gregory Chanan (JIRA)]

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

Gregory Chanan updated SOLR-8152:
-
Attachment: SOLR-8152.patch

Here's a patch implementing the above.  I haven't beasted it for too long, but 
it's gotten further than I ever got without the changes.

> Overseer Task Processor/Queue can miss responses, leading to timeouts
> -
>
> Key: SOLR-8152
> URL: https://issues.apache.org/jira/browse/SOLR-8152
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Attachments: SOLR-8152.patch
>
>
> I noticed some jenkins reports of timeouts in the 
> TestConfigSetsAPIExclusivityTest, which seemed strange given the amount of 
> work to be done is small and the timeout generous at 300 seconds.
> I added some statistics gathering and started beasting the test and sure 
> enough, some tests reported tasks taking slightly more than 300 seconds, 
> while most tests ran with a maximum task run of less than a second.  This 
> suggested something was hanging until the timeout.
> Some investigation lead to this code:
> https://github.com/apache/lucene-solr/blob/80a73535b20debb1717c6f7f11e08fc311833c88/solr/core/src/java/org/apache/solr/cloud/OverseerTaskQueue.java#L179-L194
> There appears to be a few issues here:
> {code}
>  String path = createData(dir + "/" + PREFIX, data,
>   CreateMode.PERSISTENT_SEQUENTIAL);
>   String watchID = createData(
>   dir + "/" + response_prefix + path.substring(path.lastIndexOf("-") 
> + 1),
>   null, CreateMode.EPHEMERAL);
>   Object lock = new Object();
>   LatchWatcher watcher = new LatchWatcher(lock);
>   synchronized (lock) {
> if (zookeeper.exists(watchID, watcher, true) != null) {
>   watcher.await(timeout);
> }
>   }
> {code}
> For one, the request object is created before the response object.  If the 
> request is quickly picked up and processed, two things can happen:
> 1) The response is written before the watch is set, which means we wait until 
> the timeout even though the response is ready.  This will still pass the test 
> because the response is available, the client will just wait needlessly.
> 2) The response is attempted to be written before the response node is even 
> created.  The fact that the response node doesn't exist is ignored:
> https://github.com/apache/lucene-solr/blob/80a73535b20debb1717c6f7f11e08fc311833c88/solr/core/src/java/org/apache/solr/cloud/OverseerTaskQueue.java#L92-L94
> In this case, the task is processed but the client will actually see a 
> failure because there is no response.



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

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.response.QueryResponseTest

Error Message:
The test or suite printed 8730 bytes to stdout and stderr, even though the 
limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
completely with @SuppressSysoutChecks or run with -Dtests.verbose=true

Stack Trace:
java.lang.AssertionError: The test or suite printed 8730 bytes to stdout and 
stderr, even though the limit was set to 8192 bytes. Increase the limit with 
@Limit, ignore it completely with @SuppressSysoutChecks or run with 
-Dtests.verbose=true
at __randomizedtesting.SeedInfo.seed([96A3A8B2A4180026]:0)
at 
org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:212)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11322 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.response.QueryResponseTest
   [junit4]   2> 91104 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[96A3A8B2A4180026]) [   
 ] o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 91104 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[96A3A8B2A4180026]) [   
 ] o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 91104 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[96A3A8B2A4180026]) [   
 ] o.a.s.c.SolrResourceLoader new SolrResourceLoader for deduced Solr Home: 
'solr/'
   [junit4]   2> 91104 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[96A3A8B2A4180026]) [   
 ] o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 91104 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[96A3A8B2A4180026]) [   
 ] o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 91119 INFO  
(TEST-QueryResponseTest.testRangeFacets-seed#[96A3A8B2A4180026]) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 91119 INFO  
(TEST-QueryResponseTest.testRangeFacets-seed#[96A3A8B2A4180026]) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 91119 INFO  
(TEST-QueryResponseTest.testRangeFacets-seed#[96A3A8B2A4180026]) [] 
o.a.s.c.SolrResourceLoader new SolrResourceLoader for deduced Solr Home: 'solr/'
   [junit4]   2> 91120 INFO  
(TEST-QueryResponseTest.testRangeFacets-seed#[96A3A8B2A4180026]) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 91120 INFO  
(TEST-QueryResponseTest.testRangeFacets-seed#[96A3A8B2A4180026]) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 91125 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[96A3A8B2A4180026]) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 91125 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[96A3A8B2A4180026]) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 91125 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[96A3A8B2A4180026]) [] 
o.a.s.c.SolrResourceLoader new SolrResourceLoader for deduced Solr Home: 'solr/'
   [junit4]   2> 91125 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[96A3A8B2A4180026]) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 91125 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[96A3A8B2A4180026]) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 91149 INFO  
(TEST-QueryResponseTest.testSimpleGroupResponse-seed#[96A3A8B2A4180026]) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   

[jira] [Created] (SOLR-8148) Ensure that updates are not reordered

[Ishan Chattopadhyaya (JIRA)]

Ishan Chattopadhyaya created SOLR-8148:
--

 Summary: Ensure that updates are not reordered
 Key: SOLR-8148
 URL: https://issues.apache.org/jira/browse/SOLR-8148
 Project: Solr
  Issue Type: Improvement
Reporter: Ishan Chattopadhyaya


There was discussion in SOLR-5944 (and possibly elsewhere) on exploring 
ensuring that updates are not reordered when sent from leader to replica. This 
would simplify a lot of things. 

Here's Yonik's comment from SOLR-5944:

Don't reorder updates between leader and replicas:

*create a new ConcurrentUpdateSolrClient that uses a single channel and can 
return individual responses... perhaps this fits into HTTP/2 ?
*have only a single SolrClient on the leader talk to each replica
order the udpates in _version_ order when sending
**prob multiple ways to achieve this... reserve a slot when getting the 
version, or change versions so that they are contiguous so we know if we are 
missing one.

The only additional reason to use multiple threads when sending is to increase 
indexing performance. We can also implement multi-threading for increased 
parallelism on the server side. This should also simplify clients (no more 
batching, multiple threads, etc), as well as make our general recovery system 
more robust.



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

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

[jira] [Commented] (LUCENE-6829) OfflineSorter should use Directory API

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-6829:
-

bq. StandardOpenOption.CREATE_NEW

Oh, I like this!

> OfflineSorter should use Directory API
> --
>
> Key: LUCENE-6829
> URL: https://issues.apache.org/jira/browse/LUCENE-6829
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6829.patch, LUCENE-6829.patch
>
>
> I think this is a blocker for LUCENE-6825, because the block KD-tree makes 
> heavy use of OfflineSorter and we don't want to fill up tmp space ...
> This should be a straightforward cutover, but there are some challenges, e.g. 
> the test was failing because virus checker blocked deleting of files.



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

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

[JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b82) - Build # 14173 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14173/
Java: 64bit/jdk1.9.0-ea-b82 -XX:-UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 10130 lines...]
   [junit4] JVM J2: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/temp/junit4-J2-20151009_064648_766.sysout
   [junit4] >>> JVM J2: stdout (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  SIGSEGV (0xb) at pc=0x7f4c3b253cce, pid=5925, 
tid=0x1742
   [junit4] #
   [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0-b82) (build 
1.9.0-ea-b82)
   [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-ea-b82, mixed 
mode, tiered, serial gc, linux-amd64)
   [junit4] # Problematic frame:
   [junit4] # V  [libjvm.so+0x80ccce]  
PhaseIdealLoop::build_loop_late_post(Node*)+0x13e
   [junit4] #
   [junit4] # No core dump will be written. Core dumps have been disabled. To 
enable core dumping, try "ulimit -c unlimited" before starting Java again
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J2/hs_err_pid5925.log
   [junit4] 
   [junit4] [error occurred during error reporting , id 0xb]
   [junit4] 
   [junit4] #
   [junit4] # If you would like to submit a bug report, please visit:
   [junit4] #   http://bugreport.java.com/bugreport/crash.jsp
   [junit4] #
   [junit4] <<< JVM J2: EOF 

[...truncated 220 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/temp/junit4-J1-20151009_064648_766.sysout
   [junit4] >>> JVM J1: stdout (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  SIGSEGV (0xb) at pc=0x7fa78c562cce, pid=5926, 
tid=0x1752
   [junit4] #
   [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0-b82) (build 
1.9.0-ea-b82)
   [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-ea-b82, mixed 
mode, tiered, serial gc, linux-amd64)
   [junit4] # Problematic frame:
   [junit4] # V  [libjvm.so+0x80ccce]  
PhaseIdealLoop::build_loop_late_post(Node*)+0x13e
   [junit4] #
   [junit4] # No core dump will be written. Core dumps have been disabled. To 
enable core dumping, try "ulimit -c unlimited" before starting Java again
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J1/hs_err_pid5926.log
   [junit4] 
   [junit4] [error occurred during error reporting , id 0xb]
   [junit4] 
   [junit4] #
   [junit4] # If you would like to submit a bug report, please visit:
   [junit4] #   http://bugreport.java.com/bugreport/crash.jsp
   [junit4] #
   [junit4] <<< JVM J1: EOF 

[...truncated 825 lines...]
   [junit4] ERROR: JVM J1 ended with an exception, command line: 
/home/jenkins/tools/java/64bit/jdk1.9.0-ea-b82/bin/java -XX:-UseCompressedOops 
-XX:+UseSerialGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/heapdumps -ea 
-esa -Dtests.prefix=tests -Dtests.seed=F38C1002FA9B4417 -Xmx512M -Dtests.iters= 
-Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
-Dtests.postingsformat=random -Dtests.docvaluesformat=random 
-Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random 
-Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.4.0 
-Dtests.cleanthreads=perClass 
-Djava.util.logging.config.file=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=3 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Djunit4.tempDir=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/temp
 -Dcommon.dir=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene 
-Dclover.db.dir=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/clover/db
 
-Djava.security.policy=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/tools/junit4/solr-tests.policy
 -Dtests.LUCENE_VERSION=5.4.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Djunit4.childvm.cwd=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J1
 -Djunit4.childvm.id=1 -Djunit4.childvm.count=3 -Dtests.leaveTemporary=false 
-Dtests.filterstacks=true -Dtests.disableHdfs=true 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dfile.encoding=ISO-8859-1 -classpath 

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

[Policeman Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:58290/b_ce/h/collection1: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://[ff01::213]:2/b_ce/h, 
http://[ff01::083]:2/b_ce/h, http://127.0.0.1:39220/b_ce/h/collection1]

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:58290/b_ce/h/collection1: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://[ff01::213]:2/b_ce/h, 
http://[ff01::083]:2/b_ce/h, http://127.0.0.1:39220/b_ce/h/collection1]
at 
__randomizedtesting.SeedInfo.seed([37DDBB76101BA25C:BF8984ACBEE7CFA4]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:561)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:609)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:591)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:570)
at 
org.apache.solr.handler.component.DistributedMLTComponentTest.test(DistributedMLTComponentTest.java:131)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14462/
Java: 64bit/jdk1.8.0_60 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
No stats for split in OverseerCollectionProcessor expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: No stats for split in OverseerCollectionProcessor 
expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([3F8C186777C8E24D:B7D827BDD9348FB5]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at 
org.apache.solr.cloud.OverseerStatusTest.test(OverseerStatusTest.java:91)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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 

[jira] [Commented] (SOLR-7729) ConcurrentUpdateSolrClient ignoring the collection parameter in some methods

[Nicolas Gavalda (JIRA)]

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

Nicolas Gavalda commented on SOLR-7729:
---

Jorge, did you get a chance to look into the patch?

> ConcurrentUpdateSolrClient ignoring the collection parameter in some methods
> 
>
> Key: SOLR-7729
> URL: https://issues.apache.org/jira/browse/SOLR-7729
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 5.1
>Reporter: Jorge Luis Betancourt Gonzalez
>  Labels: client, solrj
> Attachments: SOLR-7729-ConcurrentUpdateSolrClient-collection.patch
>
>
> Some of the methods in {{ConcurrentUpdateSolrClient}} accept an aditional 
> {{collection}} parameter, some of this methods are: {{add(String collection, 
> SolrInputDocument doc)}} and {{request(SolrRequest, String collection)}}. 
> This collection parameter is being ignored in this cases but works for others 
> like {{commit(String collection)}}.
> [~elyograg] noted that:
> {quote} 
> Looking into how an update request actually gets added to the background
> queue in ConcurrentUpdateSolrClient, it appears that the "collection"
> information is ignored before the request is added to the queue.
> {quote}
> From the source, when a commit is issued or the 
> {{UpdateParams.WAIT_SEARCHER}} is set in the request params the collection 
> parameter is used, otherwise the request {{UpdateRequest req}} is queued 
> without any regarding of the collection.



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b83) - Build # 14463 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14463/
Java: 64bit/jdk1.9.0-ea-b83 -XX:+UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 8520 lines...]
[javac] Compiling 874 source files to 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/classes/java
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.8
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/core/ImplicitPlugins.java:102:
 error: reference to NamedList is ambiguous
[javac] return new PluginInfo(SolrRequestHandler.TYPE, m, new 
NamedList<>(singletonMap(DEFAULTS, new NamedList(defaults))),null);
[javac]   ^
[javac]   both constructor NamedList(Entry[]) in 
NamedList and constructor NamedList(Map) in NamedList 
match
[javac]   where T is a type-variable:
[javac] T extends Object declared in class NamedList
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/core/ImplicitPlugins.java:102:
 error: incompatible types: cannot infer type arguments for NamedList<>
[javac] return new PluginInfo(SolrRequestHandler.TYPE, m, new 
NamedList<>(singletonMap(DEFAULTS, new NamedList(defaults))),null);
[javac]^
[javac] reason: no instance(s) of type variable(s) K,V exist so that 
Map conforms to Entry[]
[javac]   where K,V,T are type-variables:
[javac] K extends Object declared in method singletonMap(K,V)
[javac] V extends Object declared in method singletonMap(K,V)
[javac] T extends Object declared in class NamedList
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] Note: Some messages have been simplified; recompile with 
-Xdiags:verbose to get full output
[javac] 2 errors

[...truncated 1 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:719: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:59: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:233: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:516: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:466: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:379: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:509: 
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1944: 
Compile failed; see the compiler error output for details.

Total time: 18 minutes 54 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Updated] (SOLR-7090) Cross collection join

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-7090:
-
Attachment: (was: SOLR-7090-fulljoin.patch)

> Cross collection join
> -
>
> Key: SOLR-7090
> URL: https://issues.apache.org/jira/browse/SOLR-7090
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
> Fix For: 5.2, Trunk
>
> Attachments: SOLR-7090-fulljoin.patch, SOLR-7090.patch
>
>
> Although SOLR-4905 supports joins across collections in Cloud mode, there are 
> limitations, (i) the secondary collection must be replicated at each node 
> where the primary collection has a replica, (ii) the secondary collection 
> must be singly sharded.
> This issue explores ideas/possibilities of cross collection joins, even 
> across nodes. This will be helpful for users who wish to maintain boosts or 
> signals in a secondary, more frequently updated collection, and perform query 
> time join of these boosts/signals with results from the primary collection.



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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
Delete action failed!

Stack Trace:
java.lang.AssertionError: Delete action failed!
at 
__randomizedtesting.SeedInfo.seed([9106AF35B60B66FD:82659D5A8764DF5B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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 

[jira] [Resolved] (SOLR-7543) Create GraphQuery that allows graph traversal as a query operator.

[Yonik Seeley (JIRA)]

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

Yonik Seeley resolved SOLR-7543.

   Resolution: Fixed
Fix Version/s: Trunk

Committed.  Thanks Kevin!

> Create GraphQuery that allows graph traversal as a query operator.
> --
>
> Key: SOLR-7543
> URL: https://issues.apache.org/jira/browse/SOLR-7543
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Kevin Watters
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7543.patch, SOLR-7543.patch
>
>
> I have a GraphQuery that I implemented a long time back that allows a user to 
> specify a "startQuery" to identify which documents to start graph traversal 
> from.  It then gathers up the edge ids for those documents , optionally 
> applies an additional filter.  The query is then re-executed continually 
> until no new edge ids are identified.  I am currently hosting this code up at 
> https://github.com/kwatters/solrgraph and I would like to work with the 
> community to get some feedback and ultimately get it committed back in as a 
> lucene query.
> Here's a bit more of a description of the parameters for the query / graph 
> traversal:
> q - the initial start query that identifies the universe of documents to 
> start traversal from.
> fromField - the field name that contains the node id
> toField - the name of the field that contains the edge id(s).
> traversalFilter - this is an additional query that can be supplied to limit 
> the scope of graph traversal to just the edges that satisfy the 
> traversalFilter query.
> maxDepth - integer specifying how deep the breadth first search should go.
> returnStartNodes - boolean to determine if the documents that matched the 
> original "q" should be returned as part of the graph.
> onlyLeafNodes - boolean that filters the graph query to only return 
> documents/nodes that have no edges.
> We identify a set of documents with "q" as any arbitrary lucene query.  It 
> will collect the values in the fromField, create an OR query with those 
> values , optionally apply an additional constraint from the "traversalFilter" 
> and walk the result set until no new edges are detected.  Traversal can also 
> be stopped at N hops away as defined with the maxDepth.  This is a BFS 
> (Breadth First Search) algorithm.  Cycle detection is done by not revisiting 
> the same document for edge extraction.  
> This query operator does not keep track of how you arrived at the document, 
> but only that the traversal did arrive at the document.



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

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

[jira] [Closed] (SOLR-8086) Add support for SELECT DISTINCT queries to the SQL interface

[Joel Bernstein (JIRA)]

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

Joel Bernstein closed SOLR-8086.

   Resolution: Fixed
Fix Version/s: Trunk

> Add support for SELECT DISTINCT queries to the SQL interface
> 
>
> Key: SOLR-8086
> URL: https://issues.apache.org/jira/browse/SOLR-8086
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: Trunk
>
> Attachments: SOLR-8086.patch, SOLR-8086.patch, SOLR-8086.patch, 
> SOLR-8086.patch, SOLR-8086.patch, SOLR-8086.patch, SOLR-8086.patch
>
>
> This ticket will add the SELECT DISTINCT query to the SQL interface.
> There will be a Map/Reduce implementation using the UniqueStream and a JSON 
> Facet API implementation using the FacetStream. SQL clients will be able to 
> switch between Map/Reduce and JSON Facet API using the *aggregationMode* 
> [map_reduce or facet] http param introduced in SOLR-7903.



--
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-8150) Fix build failure due to too much printout from QueryResponseTest

[ASF subversion and git services (JIRA)]

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

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

Commit 1707817 from jan...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1707817 ]

SOLR-8150: Fix build failure due to too much output from QueryResponseTest 
(backport)

> Fix build failure due to too much printout from QueryResponseTest
> -
>
> Key: SOLR-8150
> URL: https://issues.apache.org/jira/browse/SOLR-8150
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: Trunk
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: Trunk
>
>
> Jenkins failure:
> {noformat}
> 9. okt. 2015 kl. 08.19 skrev Apache Jenkins Server 
> :
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/463/
> 1 tests failed.
> FAILED:  
> junit.framework.TestSuite.org.apache.solr.client.solrj.response.QueryResponseTest
> Error Message:
> The test or suite printed 8730 bytes to stdout and stderr, even though the 
> limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
> completely with @SuppressSysoutChecks or run with -Dtests.verbose=true
> Stack Trace:
> java.lang.AssertionError: The test or suite printed 8730 bytes to stdout and 
> stderr, even though the limit was set to 8192 bytes. Increase the limit with 
> @Limit, ignore it completely with @SuppressSysoutChecks or run with 
> -Dtests.verbose=true
>   at __randomizedtesting.SeedInfo.seed([96A3A8B2A4180026]:0)
>   at 
> org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:212)
>   at 
> com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Fix by adding {{@Limit(bytes=2)}} to class {{QueryResponseTest}}
> This applies to both Trunk and 5.x, and is easily reproducible on OSX.



--
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-7543) Create GraphQuery that allows graph traversal as a query operator.

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-7543: basic graph traversal query

> Create GraphQuery that allows graph traversal as a query operator.
> --
>
> Key: SOLR-7543
> URL: https://issues.apache.org/jira/browse/SOLR-7543
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Kevin Watters
>Priority: Minor
> Attachments: SOLR-7543.patch, SOLR-7543.patch
>
>
> I have a GraphQuery that I implemented a long time back that allows a user to 
> specify a "startQuery" to identify which documents to start graph traversal 
> from.  It then gathers up the edge ids for those documents , optionally 
> applies an additional filter.  The query is then re-executed continually 
> until no new edge ids are identified.  I am currently hosting this code up at 
> https://github.com/kwatters/solrgraph and I would like to work with the 
> community to get some feedback and ultimately get it committed back in as a 
> lucene query.
> Here's a bit more of a description of the parameters for the query / graph 
> traversal:
> q - the initial start query that identifies the universe of documents to 
> start traversal from.
> fromField - the field name that contains the node id
> toField - the name of the field that contains the edge id(s).
> traversalFilter - this is an additional query that can be supplied to limit 
> the scope of graph traversal to just the edges that satisfy the 
> traversalFilter query.
> maxDepth - integer specifying how deep the breadth first search should go.
> returnStartNodes - boolean to determine if the documents that matched the 
> original "q" should be returned as part of the graph.
> onlyLeafNodes - boolean that filters the graph query to only return 
> documents/nodes that have no edges.
> We identify a set of documents with "q" as any arbitrary lucene query.  It 
> will collect the values in the fromField, create an OR query with those 
> values , optionally apply an additional constraint from the "traversalFilter" 
> and walk the result set until no new edges are detected.  Traversal can also 
> be stopped at N hops away as defined with the maxDepth.  This is a BFS 
> (Breadth First Search) algorithm.  Cycle detection is done by not revisiting 
> the same document for edge extraction.  
> This query operator does not keep track of how you arrived at the document, 
> but only that the traversal did arrive at the document.



--
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-8150) Fix build failure due to too much printout from QueryResponseTest

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8150:
--

Probably would be good to commit this so we can get things passing again. 

I was looking for a change that caused this test to start failing but I don't 
see one.

> Fix build failure due to too much printout from QueryResponseTest
> -
>
> Key: SOLR-8150
> URL: https://issues.apache.org/jira/browse/SOLR-8150
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: Trunk
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: Trunk
>
>
> Jenkins failure:
> {noformat}
> 9. okt. 2015 kl. 08.19 skrev Apache Jenkins Server 
> :
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/463/
> 1 tests failed.
> FAILED:  
> junit.framework.TestSuite.org.apache.solr.client.solrj.response.QueryResponseTest
> Error Message:
> The test or suite printed 8730 bytes to stdout and stderr, even though the 
> limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
> completely with @SuppressSysoutChecks or run with -Dtests.verbose=true
> Stack Trace:
> java.lang.AssertionError: The test or suite printed 8730 bytes to stdout and 
> stderr, even though the limit was set to 8192 bytes. Increase the limit with 
> @Limit, ignore it completely with @SuppressSysoutChecks or run with 
> -Dtests.verbose=true
>   at __randomizedtesting.SeedInfo.seed([96A3A8B2A4180026]:0)
>   at 
> org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:212)
>   at 
> com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Fix by adding {{@Limit(bytes=2)}} to class {{QueryResponseTest}}
> This applies to both Trunk and 5.x, and is easily reproducible on OSX.



--
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-8150) Fix build failure due to too much printout from QueryResponseTest

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8150 at 10/9/15 8:53 PM:
---

Ah, just saw the commit. Thanks!


was (Author: joel.bernstein):
Ah, just the commit. Thanks!

> Fix build failure due to too much printout from QueryResponseTest
> -
>
> Key: SOLR-8150
> URL: https://issues.apache.org/jira/browse/SOLR-8150
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: Trunk
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: Trunk
>
>
> Jenkins failure:
> {noformat}
> 9. okt. 2015 kl. 08.19 skrev Apache Jenkins Server 
> :
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/463/
> 1 tests failed.
> FAILED:  
> junit.framework.TestSuite.org.apache.solr.client.solrj.response.QueryResponseTest
> Error Message:
> The test or suite printed 8730 bytes to stdout and stderr, even though the 
> limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
> completely with @SuppressSysoutChecks or run with -Dtests.verbose=true
> Stack Trace:
> java.lang.AssertionError: The test or suite printed 8730 bytes to stdout and 
> stderr, even though the limit was set to 8192 bytes. Increase the limit with 
> @Limit, ignore it completely with @SuppressSysoutChecks or run with 
> -Dtests.verbose=true
>   at __randomizedtesting.SeedInfo.seed([96A3A8B2A4180026]:0)
>   at 
> org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:212)
>   at 
> com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Fix by adding {{@Limit(bytes=2)}} to class {{QueryResponseTest}}
> This applies to both Trunk and 5.x, and is easily reproducible on OSX.



--
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-8150) Fix build failure due to too much printout from QueryResponseTest

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8150:
--

Ah, just the commit. Thanks!

> Fix build failure due to too much printout from QueryResponseTest
> -
>
> Key: SOLR-8150
> URL: https://issues.apache.org/jira/browse/SOLR-8150
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: Trunk
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: Trunk
>
>
> Jenkins failure:
> {noformat}
> 9. okt. 2015 kl. 08.19 skrev Apache Jenkins Server 
> :
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/463/
> 1 tests failed.
> FAILED:  
> junit.framework.TestSuite.org.apache.solr.client.solrj.response.QueryResponseTest
> Error Message:
> The test or suite printed 8730 bytes to stdout and stderr, even though the 
> limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
> completely with @SuppressSysoutChecks or run with -Dtests.verbose=true
> Stack Trace:
> java.lang.AssertionError: The test or suite printed 8730 bytes to stdout and 
> stderr, even though the limit was set to 8192 bytes. Increase the limit with 
> @Limit, ignore it completely with @SuppressSysoutChecks or run with 
> -Dtests.verbose=true
>   at __randomizedtesting.SeedInfo.seed([96A3A8B2A4180026]:0)
>   at 
> org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:212)
>   at 
> com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Fix by adding {{@Limit(bytes=2)}} to class {{QueryResponseTest}}
> This applies to both Trunk and 5.x, and is easily reproducible on OSX.



--
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-5944) Support updates of numeric DocValues

[Yonik Seeley (JIRA)]

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

Yonik Seeley edited comment on SOLR-5944 at 10/9/15 9:04 PM:
-

Stepping back and looking the high level view of Ishan's last 
proposal/approach, I think it looks fine.
Once we get into true partial udpates, we can't really allow reorders, so they 
either have to be ordered on the sender side, or the receiver side.  From a 
complexity POV, once we have to order certain types of updates, it's no more 
complex to order them all.

If I could wave a magic wand, we'd have the order-on-the-sender-side approach, 
because it should also solve known weaknesses like I appear to be hitting in 
SOLR-8129, but I recognize it would be a lot of work.  Of course, reordering on 
the receiver side is not going to be a picnic either - the synchronization 
involved may be quite difficult to get right.

edit: some of the other parts of the design, like the prevPointer & prevVersion 
seem fine regardless of how other parts of this puzzle are solved.


was (Author: ysee...@gmail.com):
Stepping back and looking the high level view of Ishan's last 
proposal/approach, I think it looks fine.
Once we get into true partial udpates, we can't really allow reorders, so they 
either have to be ordered on the sender side, or the receiver side.  From a 
complexity POV, once we have to order certain types of updates, it's no more 
complex to order them all.

If I could wave a magic wand, we'd have the order-on-the-sender-side approach, 
because it should also solve known weaknesses like I appear to be hitting in 
SOLR-8129, but I recognize it would be a lot of work.  Of course, reordering on 
the receiver side is not going to be a picnic either - the synchronization 
involved may be quite difficult to get right.

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



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

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

[jira] [Updated] (SOLR-8039) Add new book: Apache Solr Search Patterns

[Jayant Kumar (JIRA)]

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

Jayant Kumar updated SOLR-8039:
---
Attachment: book_solr_patterns.jpg
solr-8039.patch

I have attached the patch with changes to the site. Please review.
book_solr_patterns.jpg goes inside assets/images (complete path : 
trunk/content/solr/assets/images) folder.

> Add new book: Apache Solr Search Patterns
> -
>
> Key: SOLR-8039
> URL: https://issues.apache.org/jira/browse/SOLR-8039
> Project: Solr
>  Issue Type: Task
>Reporter: Zico Fernandes
> Attachments: book_solr_patterns.jpg, solr-8039.patch
>
>
> Jayant Kumar is proud to announce the book 'Apache Solr Search Patterns' by 
> Packt Publishing. This book is for developers who have prior knowledge on 
> Solr and are looking at procuring advanced strategies for improving their 
> search using Solr. Also, if you work with analytics to generate graphs and 
> reports using Solr and you are a search architect who is looking forward to 
> scale your search using Solr, then this book is a perfect guide for you.
> Apache Solr Search Patterns begins with a brief introduction of analyzers and 
> tokenizers to understand the challenges associated with implementing 
> large-scale indexing and multilingual search functionality. It then moves on 
> to working with custom queries and understanding how filters work internally. 
> While doing so, it also helps the readers create their own query language or 
> Solr plugin that does proximity searches. 
> Furthermore, the book discusses how Solr can be used for real-time analytics 
> and tackle problems faced during its implementation in e-commerce search. It 
> then dives into the spatial features such as indexing strategies and 
> search/filtering strategies for a spatial search. And also do an in-depth 
> analysis of problems faced in an ad serving platform and how Solr can be used 
> to solve these problems.
> Click here to read more about the Apache Solr Search Patterns: 
> http://bit.ly/1J2neZ9



--
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_60) - Build # 14471 - Still Failing!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
Delete action failed!

Stack Trace:
java.lang.AssertionError: Delete action failed!
at 
__randomizedtesting.SeedInfo.seed([748EC24293FBC0B5:67EDF02DA2947913]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.client.solrj.TestLBHttpSolrClient.testReliability

Error Message:
No live SolrServers available to handle this request

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request
at 
__randomizedtesting.SeedInfo.seed([8AAF02C30DE7AFD9:4B67DF85AC817E70]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:571)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
at 
org.apache.solr.client.solrj.TestLBHttpSolrClient.testReliability(TestLBHttpSolrClient.java:221)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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:367)
at 

[jira] [Updated] (SOLR-8150) Fix build failure due to too much printout from QueryResponseTest

[JIRA]

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

Jan Høydahl updated SOLR-8150:
--
Fix Version/s: 5.4

> Fix build failure due to too much printout from QueryResponseTest
> -
>
> Key: SOLR-8150
> URL: https://issues.apache.org/jira/browse/SOLR-8150
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 5.3, Trunk
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 5.4, Trunk
>
>
> Jenkins failure:
> {noformat}
> 9. okt. 2015 kl. 08.19 skrev Apache Jenkins Server 
> :
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/463/
> 1 tests failed.
> FAILED:  
> junit.framework.TestSuite.org.apache.solr.client.solrj.response.QueryResponseTest
> Error Message:
> The test or suite printed 8730 bytes to stdout and stderr, even though the 
> limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
> completely with @SuppressSysoutChecks or run with -Dtests.verbose=true
> Stack Trace:
> java.lang.AssertionError: The test or suite printed 8730 bytes to stdout and 
> stderr, even though the limit was set to 8192 bytes. Increase the limit with 
> @Limit, ignore it completely with @SuppressSysoutChecks or run with 
> -Dtests.verbose=true
>   at __randomizedtesting.SeedInfo.seed([96A3A8B2A4180026]:0)
>   at 
> org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:212)
>   at 
> com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Fix by adding {{@Limit(bytes=2)}} to class {{QueryResponseTest}}
> This applies to both Trunk and 5.x, and is easily reproducible on OSX.



--
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-8150) Fix build failure due to too much printout from QueryResponseTest

[JIRA]

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

Jan Høydahl updated SOLR-8150:
--
Affects Version/s: 5.3

> Fix build failure due to too much printout from QueryResponseTest
> -
>
> Key: SOLR-8150
> URL: https://issues.apache.org/jira/browse/SOLR-8150
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 5.3, Trunk
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 5.4, Trunk
>
>
> Jenkins failure:
> {noformat}
> 9. okt. 2015 kl. 08.19 skrev Apache Jenkins Server 
> :
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/463/
> 1 tests failed.
> FAILED:  
> junit.framework.TestSuite.org.apache.solr.client.solrj.response.QueryResponseTest
> Error Message:
> The test or suite printed 8730 bytes to stdout and stderr, even though the 
> limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
> completely with @SuppressSysoutChecks or run with -Dtests.verbose=true
> Stack Trace:
> java.lang.AssertionError: The test or suite printed 8730 bytes to stdout and 
> stderr, even though the limit was set to 8192 bytes. Increase the limit with 
> @Limit, ignore it completely with @SuppressSysoutChecks or run with 
> -Dtests.verbose=true
>   at __randomizedtesting.SeedInfo.seed([96A3A8B2A4180026]:0)
>   at 
> org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:212)
>   at 
> com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Fix by adding {{@Limit(bytes=2)}} to class {{QueryResponseTest}}
> This applies to both Trunk and 5.x, and is easily reproducible on OSX.



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

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

[JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b83) - Build # 14181 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14181/
Java: 64bit/jdk1.9.0-ea-b83 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=9241, 
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:746)2) Thread[id=9242, 
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:746)3) Thread[id=9240, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)4) Thread[id=9244, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)5) Thread[id=9243, 
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:746)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=9241, 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 

[jira] [Updated] (SOLR-8150) Fix build failure due to too much printout from QueryResponseTest

[JIRA]

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

Jan Høydahl updated SOLR-8150:
--
Description: 
Jenkins failure:
{noformat}
9. okt. 2015 kl. 08.19 skrev Apache Jenkins Server :

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.response.QueryResponseTest

Error Message:
The test or suite printed 8730 bytes to stdout and stderr, even though the 
limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
completely with @SuppressSysoutChecks or run with -Dtests.verbose=true

Stack Trace:
java.lang.AssertionError: The test or suite printed 8730 bytes to stdout and 
stderr, even though the limit was set to 8192 bytes. Increase the limit with 
@Limit, ignore it completely with @SuppressSysoutChecks or run with 
-Dtests.verbose=true
at __randomizedtesting.SeedInfo.seed([96A3A8B2A4180026]:0)
at 
org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:212)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
{noformat}

Fix by adding {{@Limit(bytes=2)}} to class {{QueryResponseTest}}

This applies to both Trunk and 5.x, and is easily reproducible on OSX.

  was:
Jenkins failure:
{noformat}
9. okt. 2015 kl. 08.19 skrev Apache Jenkins Server :

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.response.QueryResponseTest

Error Message:
The test or suite printed 8730 bytes to stdout and stderr, even though the 
limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
completely with @SuppressSysoutChecks or run with -Dtests.verbose=true

Stack Trace:
java.lang.AssertionError: The test or suite printed 8730 bytes to stdout and 
stderr, even though the limit was set to 8192 bytes. Increase the limit with 
@Limit, ignore it completely with @SuppressSysoutChecks or run with 
-Dtests.verbose=true
at __randomizedtesting.SeedInfo.seed([96A3A8B2A4180026]:0)
at 
org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:212)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
{noformat}

Fix by adding
{code}
@Limit(bytes=15)
{code}
QueryResponseTest



> Fix build failure due to too much printout from QueryResponseTest
> -
>
> Key: SOLR-8150
> URL: https://issues.apache.org/jira/browse/SOLR-8150
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: Trunk
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: Trunk
>
>
> Jenkins failure:
> {noformat}
> 9. okt. 2015 kl. 08.19 skrev Apache Jenkins Server 
> :
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/463/
> 1 tests failed.
> FAILED:  
> junit.framework.TestSuite.org.apache.solr.client.solrj.response.QueryResponseTest
> Error Message:
> The test or suite printed 

[jira] [Commented] (SOLR-8150) Fix build failure due to too much printout from QueryResponseTest

[ASF subversion and git services (JIRA)]

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

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

Commit 1707813 from jan...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1707813 ]

SOLR-8150: Fix build failure due to too much output from QueryResponseTest

> Fix build failure due to too much printout from QueryResponseTest
> -
>
> Key: SOLR-8150
> URL: https://issues.apache.org/jira/browse/SOLR-8150
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: Trunk
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: Trunk
>
>
> Jenkins failure:
> {noformat}
> 9. okt. 2015 kl. 08.19 skrev Apache Jenkins Server 
> :
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/463/
> 1 tests failed.
> FAILED:  
> junit.framework.TestSuite.org.apache.solr.client.solrj.response.QueryResponseTest
> Error Message:
> The test or suite printed 8730 bytes to stdout and stderr, even though the 
> limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
> completely with @SuppressSysoutChecks or run with -Dtests.verbose=true
> Stack Trace:
> java.lang.AssertionError: The test or suite printed 8730 bytes to stdout and 
> stderr, even though the limit was set to 8192 bytes. Increase the limit with 
> @Limit, ignore it completely with @SuppressSysoutChecks or run with 
> -Dtests.verbose=true
>   at __randomizedtesting.SeedInfo.seed([96A3A8B2A4180026]:0)
>   at 
> org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:212)
>   at 
> com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Fix by adding {{@Limit(bytes=2)}} to class {{QueryResponseTest}}
> This applies to both Trunk and 5.x, and is easily reproducible on OSX.



--
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 # 2790 - Still Failing!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.response.QueryResponseTest

Error Message:
The test or suite printed 8780 bytes to stdout and stderr, even though the 
limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
completely with @SuppressSysoutChecks or run with -Dtests.verbose=true

Stack Trace:
java.lang.AssertionError: The test or suite printed 8780 bytes to stdout and 
stderr, even though the limit was set to 8192 bytes. Increase the limit with 
@Limit, ignore it completely with @SuppressSysoutChecks or run with 
-Dtests.verbose=true
at __randomizedtesting.SeedInfo.seed([DD3AC88B64A2BECF]:0)
at 
org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:212)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11268 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.response.QueryResponseTest
   [junit4]   2> 133245 INFO  
(TEST-QueryResponseTest.testSimpleGroupResponse-seed#[DD3AC88B64A2BECF]) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 133245 INFO  
(TEST-QueryResponseTest.testSimpleGroupResponse-seed#[DD3AC88B64A2BECF]) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 133245 INFO  
(TEST-QueryResponseTest.testSimpleGroupResponse-seed#[DD3AC88B64A2BECF]) [] 
o.a.s.c.SolrResourceLoader new SolrResourceLoader for deduced Solr Home: 'solr/'
   [junit4]   2> 133245 INFO  
(TEST-QueryResponseTest.testSimpleGroupResponse-seed#[DD3AC88B64A2BECF]) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 133245 INFO  
(TEST-QueryResponseTest.testSimpleGroupResponse-seed#[DD3AC88B64A2BECF]) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 133258 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[DD3AC88B64A2BECF]) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 133258 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[DD3AC88B64A2BECF]) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 133258 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[DD3AC88B64A2BECF]) [] 
o.a.s.c.SolrResourceLoader new SolrResourceLoader for deduced Solr Home: 'solr/'
   [junit4]   2> 133258 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[DD3AC88B64A2BECF]) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 133258 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[DD3AC88B64A2BECF]) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 133263 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[DD3AC88B64A2BECF]) [   
 ] o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 133263 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[DD3AC88B64A2BECF]) [   
 ] o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 133263 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[DD3AC88B64A2BECF]) [   
 ] o.a.s.c.SolrResourceLoader new SolrResourceLoader for deduced Solr Home: 
'solr/'
   [junit4]   2> 133263 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[DD3AC88B64A2BECF]) [   
 ] o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 133263 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[DD3AC88B64A2BECF]) [   
 ] o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 133279 INFO  

[jira] [Commented] (SOLR-8086) Add support for SELECT DISTINCT queries to the SQL interface

[ASF subversion and git services (JIRA)]

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

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

Commit 1707819 from [~joel.bernstein] in branch 'dev/trunk'
[ https://svn.apache.org/r1707819 ]

SOLR-8086: Add support for SELECT DISTINCT queries to the SQL interface

> Add support for SELECT DISTINCT queries to the SQL interface
> 
>
> Key: SOLR-8086
> URL: https://issues.apache.org/jira/browse/SOLR-8086
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-8086.patch, SOLR-8086.patch, SOLR-8086.patch, 
> SOLR-8086.patch, SOLR-8086.patch, SOLR-8086.patch, SOLR-8086.patch
>
>
> This ticket will add the SELECT DISTINCT query to the SQL interface.
> There will be a Map/Reduce implementation using the UniqueStream and a JSON 
> Facet API implementation using the FacetStream. SQL clients will be able to 
> switch between Map/Reduce and JSON Facet API using the *aggregationMode* 
> [map_reduce or facet] http param introduced in SOLR-7903.



--
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-8113) Accept replacement strings in CloneFieldUpdateProcessorFactory

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8113:


Gus, just read through your patch.

My chief concerns are:

# you've redefined the semantics of how the {{dest}} string is interpreted when 
a {{fieldRegex}} is used to identify the source (so there's a back compat break 
there depending on the value of {{dest}})
# You've designed the "config syntax" for this new feature around the 
requirement that it can _only_ be used if at least one {{fieldRegex}} is used 
to identify the source fields ...

The original purpose of the {{FieldSelector}} API was to provide more general 
appoaches for configuring which fields and {{UpdateProcessor}} should care 
about beyond simple string field name glob/pattern matching.  I think that 
pattern replacements for _destination_ field naming should (in general) be 
independent of the original selection criteria, so that a user could say 
something like...

bq. I want to make a copy of _any_ {{StrField}} in my documents such that the 
copy has the same name as the original but with {{_t}} appended.

...and that shold be possible with this feature, regardless of wether the user 
is using an specific naming convention (ie "*_s") for all StrFields in their 
index, using some syntax that might look like this...

{code}

  
  
solr.StrField
  
  
  
.*
$0_t
  

{code}

...while prefix\->prefix and suffix\->suffix style of cloning similar to what 
{{copyField}} supports could also be specified.  Example: a {{}} equivilent would be...

{code}

  
  
^(.*)_s$
  
  
  
^(.*)_s$
$1_t
  

{code}


That's fairly verbose, but if we get the nuts & blots of the general case 
implemented, then it should be trivial to add syntactic sugar to simplify the 
configuration...

{code}

  
  
  ^(.*)_s$
  $1_t

{code}

What do you think?

> Accept replacement strings in CloneFieldUpdateProcessorFactory
> --
>
> Key: SOLR-8113
> URL: https://issues.apache.org/jira/browse/SOLR-8113
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 5.3
>Reporter: Gus Heck
> Attachments: SOLR-8113.patch
>
>
> Presently CloneFieldUpdateProcessorFactory accepts regular expressions to 
> select source fields, which mirrors wildcards in the source for copyField in 
> the schema. This patch adds a counterpart to copyField's wildcards in the 
> dest attribute by interpreting the dest parameter as a regex replacement 
> string.



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b83) - Build # 14474 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14474/
Java: 32bit/jdk1.9.0-ea-b83 -server -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 8537 lines...]
[javac] Compiling 879 source files to 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/classes/java
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.8
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/core/ImplicitPlugins.java:102:
 error: reference to NamedList is ambiguous
[javac] return new PluginInfo(SolrRequestHandler.TYPE, m, new 
NamedList<>(singletonMap(DEFAULTS, new NamedList(defaults))),null);
[javac]   ^
[javac]   both constructor NamedList(Entry[]) in 
NamedList and constructor NamedList(Map) in NamedList 
match
[javac]   where T is a type-variable:
[javac] T extends Object declared in class NamedList
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/core/ImplicitPlugins.java:102:
 error: incompatible types: cannot infer type arguments for NamedList<>
[javac] return new PluginInfo(SolrRequestHandler.TYPE, m, new 
NamedList<>(singletonMap(DEFAULTS, new NamedList(defaults))),null);
[javac]^
[javac] reason: no instance(s) of type variable(s) K,V exist so that 
Map conforms to Entry[]
[javac]   where K,V,T are type-variables:
[javac] K extends Object declared in method singletonMap(K,V)
[javac] V extends Object declared in method singletonMap(K,V)
[javac] T extends Object declared in class NamedList
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] Note: Some messages have been simplified; recompile with 
-Xdiags:verbose to get full output
[javac] 2 errors

[...truncated 1 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:719: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:59: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:233: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:516: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:466: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:379: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:509: 
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1944: 
Compile failed; see the compiler error output for details.

Total time: 19 minutes 54 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Commented] (LUCENE-6825) Add multidimensional byte[] indexing support to Lucene

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-6825:
--

Exciting!  Mike, have you considered a new module for this; like "bkd" or 
"multidimensional"?  Or of course the existing spatial module? I wonder what 
others think.

> Add multidimensional byte[] indexing support to Lucene
> --
>
> Key: LUCENE-6825
> URL: https://issues.apache.org/jira/browse/LUCENE-6825
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk
>
> Attachments: LUCENE-6825.patch
>
>
> I think we should graduate the low-level block KD-tree data structure
> from sandbox into Lucene's core?
> This can be used for very fast 1D range filtering for numerics,
> removing the 8 byte (long/double) limit we have today, so e.g. we
> could efficiently support BigInteger, BigDecimal, IPv6 addresses, etc.
> It can also be used for > 1D use cases, like 2D (lat/lon) and 3D
> (x/y/z with geo3d) geo shape intersection searches.
> The idea here is to add a new part of the Codec API (DimensionalFormat
> maybe?) that can do low-level N-dim point indexing and at runtime
> exposes only an "intersect" method.
> It should give sizable performance gains (smaller index, faster
> searching) over what we have today, and even over what auto-prefix
> with efficient numeric terms would do.
> There are many steps here ... and I think adding this is analogous to
> how we added FSTs, where we first added low level data structure
> support and then gradually cutover the places that benefit from an
> FST.
> So for the first step, I'd like to just add the low-level block
> KD-tree impl into oal.util.bkd, but make a couple improvements over
> what we have now in sandbox:
>   * Use byte[] as the value not int (@rjernst's good idea!)
>   * Generalize it to arbitrary dimensions vs. specialized/forked 1D,
> 2D, 3D cases we have now
> This is already hard enough :)  After that we can build the
> DimensionalFormat on top, then cutover existing specialized block
> KD-trees.  We also need to fix OfflineSorter to use Directory API so
> we don't fill up /tmp when building a block KD-tree.
> A block KD-tree is at heart an inverted data structure, like postings,
> but is also similar to auto-prefix in that it "picks" proper
> N-dimensional "terms" (leaf blocks) to index based on how the specific
> data being indexed is distributed.  I think this is a big part of why
> it's so fast, i.e. in contrast to today where we statically slice up
> the space into the same terms regardless of the data (trie shifting,
> morton codes, geohash, hilbert curves, etc.)
> I'm marking this as trunk only for now... as we iterate we can see if
> it could maybe go back to 5.x...



--
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-8152) Overseer Task Processor/Queue can miss responses, leading to timeouts

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-8152:
-

Thanks Gregory, good catch! Your patch changes the response node from EPHEMERAL 
to EPHEMERAL_SEQUENTIAL. Was that intentional?

Another option could be to create both nodes together in a 'multi' operation 
but this approach also looks fine.

> Overseer Task Processor/Queue can miss responses, leading to timeouts
> -
>
> Key: SOLR-8152
> URL: https://issues.apache.org/jira/browse/SOLR-8152
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Attachments: SOLR-8152.patch
>
>
> I noticed some jenkins reports of timeouts in the 
> TestConfigSetsAPIExclusivityTest, which seemed strange given the amount of 
> work to be done is small and the timeout generous at 300 seconds.
> I added some statistics gathering and started beasting the test and sure 
> enough, some tests reported tasks taking slightly more than 300 seconds, 
> while most tests ran with a maximum task run of less than a second.  This 
> suggested something was hanging until the timeout.
> Some investigation lead to this code:
> https://github.com/apache/lucene-solr/blob/80a73535b20debb1717c6f7f11e08fc311833c88/solr/core/src/java/org/apache/solr/cloud/OverseerTaskQueue.java#L179-L194
> There appears to be a few issues here:
> {code}
>  String path = createData(dir + "/" + PREFIX, data,
>   CreateMode.PERSISTENT_SEQUENTIAL);
>   String watchID = createData(
>   dir + "/" + response_prefix + path.substring(path.lastIndexOf("-") 
> + 1),
>   null, CreateMode.EPHEMERAL);
>   Object lock = new Object();
>   LatchWatcher watcher = new LatchWatcher(lock);
>   synchronized (lock) {
> if (zookeeper.exists(watchID, watcher, true) != null) {
>   watcher.await(timeout);
> }
>   }
> {code}
> For one, the request object is created before the response object.  If the 
> request is quickly picked up and processed, two things can happen:
> 1) The response is written before the watch is set, which means we wait until 
> the timeout even though the response is ready.  This will still pass the test 
> because the response is available, the client will just wait needlessly.
> 2) The response is attempted to be written before the response node is even 
> created.  The fact that the response node doesn't exist is ignored:
> https://github.com/apache/lucene-solr/blob/80a73535b20debb1717c6f7f11e08fc311833c88/solr/core/src/java/org/apache/solr/cloud/OverseerTaskQueue.java#L92-L94
> In this case, the task is processed but the client will actually see a 
> failure because there is no response.



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

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

[jira] [Updated] (SOLR-8153) Upgrade to Presto SQL Parser to version .122

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8153:
-
Summary: Upgrade to Presto SQL Parser to version .122  (was: Upgrade to 
Presto parser to version .122)

> Upgrade to Presto SQL Parser to version .122
> 
>
> Key: SOLR-8153
> URL: https://issues.apache.org/jira/browse/SOLR-8153
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Joel Bernstein
>Priority: Minor
>
> The version of the Presto parser currently in Solr is lower casing all SQL 
> identifiers unless they are string literals (single quotes). This appears to 
> be happening in the QualifiedName class.
> The latest version of the Presto parser has changed the QualifiedName class 
> to maintain the original casing. This will allow Solr to maintain the 
> original case of SQL identifiers without requiring quoted identifiers.



--
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-8153) Upgrade to Presto parser to version .122

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8153:
-
Summary: Upgrade to Presto parser to version .122  (was: Upgrade to Presto 
parser .122)

> Upgrade to Presto parser to version .122
> 
>
> Key: SOLR-8153
> URL: https://issues.apache.org/jira/browse/SOLR-8153
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Joel Bernstein
>Priority: Minor
>
> The version of the Presto parser currently in Solr is lower casing all SQL 
> identifiers unless they are string literals (single quotes). This appears to 
> be happening in the QualifiedName class.
> The latest version of the Presto parser has changed the QualifiedName class 
> to maintain the original casing. This will allow Solr to maintain the 
> original case of SQL identifiers without requiring quoted identifiers.



--
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-8153) Upgrade to Presto parser .122

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-8153:


 Summary: Upgrade to Presto parser .122
 Key: SOLR-8153
 URL: https://issues.apache.org/jira/browse/SOLR-8153
 Project: Solr
  Issue Type: Improvement
  Components: SolrJ
Affects Versions: Trunk
Reporter: Joel Bernstein
Priority: Minor


The version of the Presto parser currently in Solr is lower casing all SQL 
identifiers unless they are string literals (single quotes). This appears to be 
happening in the QualifiedName class.

The latest version of the Presto parser has changed the QualifiedName class to 
maintain the original casing. This will allow Solr to maintain the original 
case of SQL identifiers without requiring quoted identifiers.



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b83) - Build # 14475 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14475/
Java: 32bit/jdk1.9.0-ea-b83 -client -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 8534 lines...]
[javac] Compiling 879 source files to 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/classes/java
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.8
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/core/ImplicitPlugins.java:102:
 error: reference to NamedList is ambiguous
[javac] return new PluginInfo(SolrRequestHandler.TYPE, m, new 
NamedList<>(singletonMap(DEFAULTS, new NamedList(defaults))),null);
[javac]   ^
[javac]   both constructor NamedList(Entry[]) in 
NamedList and constructor NamedList(Map) in NamedList 
match
[javac]   where T is a type-variable:
[javac] T extends Object declared in class NamedList
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/core/ImplicitPlugins.java:102:
 error: incompatible types: cannot infer type arguments for NamedList<>
[javac] return new PluginInfo(SolrRequestHandler.TYPE, m, new 
NamedList<>(singletonMap(DEFAULTS, new NamedList(defaults))),null);
[javac]^
[javac] reason: no instance(s) of type variable(s) K,V exist so that 
Map conforms to Entry[]
[javac]   where K,V,T are type-variables:
[javac] K extends Object declared in method singletonMap(K,V)
[javac] V extends Object declared in method singletonMap(K,V)
[javac] T extends Object declared in class NamedList
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] Note: Some messages have been simplified; recompile with 
-Xdiags:verbose to get full output
[javac] 2 errors

[...truncated 1 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:719: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:59: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:233: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:516: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:466: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:379: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:509: 
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1944: 
Compile failed; see the compiler error output for details.

Total time: 22 minutes 47 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_60) - Build # 14186 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14186/
Java: 32bit/jdk1.8.0_60 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
Delete action failed!

Stack Trace:
java.lang.AssertionError: Delete action failed!
at 
__randomizedtesting.SeedInfo.seed([75BBE60B308B435:14388C0F82670D93]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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 

[jira] [Updated] (SOLR-7090) Cross collection join

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-7090:
-
Attachment: (was: SOLR-7090-fulljoin.patch)

> Cross collection join
> -
>
> Key: SOLR-7090
> URL: https://issues.apache.org/jira/browse/SOLR-7090
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
> Fix For: 5.2, Trunk
>
> Attachments: SOLR-7090-fulljoin.patch, SOLR-7090.patch
>
>
> Although SOLR-4905 supports joins across collections in Cloud mode, there are 
> limitations, (i) the secondary collection must be replicated at each node 
> where the primary collection has a replica, (ii) the secondary collection 
> must be singly sharded.
> This issue explores ideas/possibilities of cross collection joins, even 
> across nodes. This will be helpful for users who wish to maintain boosts or 
> signals in a secondary, more frequently updated collection, and perform query 
> time join of these boosts/signals with results from the primary collection.



--
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-7090) Cross collection join

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-7090:
-
Attachment: SOLR-7090-fulljoin.patch

All tests passing I think.

> Cross collection join
> -
>
> Key: SOLR-7090
> URL: https://issues.apache.org/jira/browse/SOLR-7090
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
> Fix For: 5.2, Trunk
>
> Attachments: SOLR-7090-fulljoin.patch, SOLR-7090.patch
>
>
> Although SOLR-4905 supports joins across collections in Cloud mode, there are 
> limitations, (i) the secondary collection must be replicated at each node 
> where the primary collection has a replica, (ii) the secondary collection 
> must be singly sharded.
> This issue explores ideas/possibilities of cross collection joins, even 
> across nodes. This will be helpful for users who wish to maintain boosts or 
> signals in a secondary, more frequently updated collection, and perform query 
> time join of these boosts/signals with results from the primary collection.



--
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-5944) Support updates of numeric DocValues

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-5944:


Stepping back and looking the high level view of Ishan's last 
proposal/approach, I think it looks fine.
Once we get into true partial udpates, we can't really allow reorders, so they 
either have to be ordered on the sender side, or the receiver side.  From a 
complexity POV, once we have to order certain types of updates, it's no more 
complex to order them all.

If I could wave a magic wand, we'd have the order-on-the-sender-side approach, 
because it should also solve known weaknesses like I appear to be hitting in 
SOLR-8129, but I recognize it would be a lot of work.  Of course, reordering on 
the receiver side is not going to be a picnic either - the synchronization 
involved may be quite difficult to get right.

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



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

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

[jira] [Resolved] (SOLR-8150) Fix build failure due to too much printout from QueryResponseTest

[JIRA]

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

Jan Høydahl resolved SOLR-8150.
---
Resolution: Fixed

> Fix build failure due to too much printout from QueryResponseTest
> -
>
> Key: SOLR-8150
> URL: https://issues.apache.org/jira/browse/SOLR-8150
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 5.3, Trunk
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 5.4, Trunk
>
>
> Jenkins failure:
> {noformat}
> 9. okt. 2015 kl. 08.19 skrev Apache Jenkins Server 
> :
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/463/
> 1 tests failed.
> FAILED:  
> junit.framework.TestSuite.org.apache.solr.client.solrj.response.QueryResponseTest
> Error Message:
> The test or suite printed 8730 bytes to stdout and stderr, even though the 
> limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
> completely with @SuppressSysoutChecks or run with -Dtests.verbose=true
> Stack Trace:
> java.lang.AssertionError: The test or suite printed 8730 bytes to stdout and 
> stderr, even though the limit was set to 8192 bytes. Increase the limit with 
> @Limit, ignore it completely with @SuppressSysoutChecks or run with 
> -Dtests.verbose=true
>   at __randomizedtesting.SeedInfo.seed([96A3A8B2A4180026]:0)
>   at 
> org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:212)
>   at 
> com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Fix by adding {{@Limit(bytes=2)}} to class {{QueryResponseTest}}
> This applies to both Trunk and 5.x, and is easily reproducible on OSX.



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b83) - Build # 14468 - Still Failing!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 8512 lines...]
[javac] Compiling 874 source files to 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/classes/java
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.8
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/core/ImplicitPlugins.java:102:
 error: reference to NamedList is ambiguous
[javac] return new PluginInfo(SolrRequestHandler.TYPE, m, new 
NamedList<>(singletonMap(DEFAULTS, new NamedList(defaults))),null);
[javac]   ^
[javac]   both constructor NamedList(Entry[]) in 
NamedList and constructor NamedList(Map) in NamedList 
match
[javac]   where T is a type-variable:
[javac] T extends Object declared in class NamedList
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/core/ImplicitPlugins.java:102:
 error: incompatible types: cannot infer type arguments for NamedList<>
[javac] return new PluginInfo(SolrRequestHandler.TYPE, m, new 
NamedList<>(singletonMap(DEFAULTS, new NamedList(defaults))),null);
[javac]^
[javac] reason: no instance(s) of type variable(s) K,V exist so that 
Map conforms to Entry[]
[javac]   where K,V,T are type-variables:
[javac] K extends Object declared in method singletonMap(K,V)
[javac] V extends Object declared in method singletonMap(K,V)
[javac] T extends Object declared in class NamedList
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] Note: Some messages have been simplified; recompile with 
-Xdiags:verbose to get full output
[javac] 2 errors

[...truncated 1 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:719: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:59: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:233: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:516: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:466: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:379: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:509: 
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1944: 
Compile failed; see the compiler error output for details.

Total time: 19 minutes 42 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
Delete action failed!

Stack Trace:
java.lang.AssertionError: Delete action failed!
at 
__randomizedtesting.SeedInfo.seed([F70A4B6AE593539A:E4697905D4FCEA3C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.response.QueryResponseTest

Error Message:
The test or suite printed 8730 bytes to stdout and stderr, even though the 
limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
completely with @SuppressSysoutChecks or run with -Dtests.verbose=true

Stack Trace:
java.lang.AssertionError: The test or suite printed 8730 bytes to stdout and 
stderr, even though the limit was set to 8192 bytes. Increase the limit with 
@Limit, ignore it completely with @SuppressSysoutChecks or run with 
-Dtests.verbose=true
at __randomizedtesting.SeedInfo.seed([BEBE5A97A779D553]:0)
at 
org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:212)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11283 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.response.QueryResponseTest
   [junit4]   2> 76434 INFO  
(TEST-QueryResponseTest.testSimpleGroupResponse-seed#[BEBE5A97A779D553]) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 76434 INFO  
(TEST-QueryResponseTest.testSimpleGroupResponse-seed#[BEBE5A97A779D553]) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 76434 INFO  
(TEST-QueryResponseTest.testSimpleGroupResponse-seed#[BEBE5A97A779D553]) [] 
o.a.s.c.SolrResourceLoader new SolrResourceLoader for deduced Solr Home: 'solr/'
   [junit4]   2> 76434 INFO  
(TEST-QueryResponseTest.testSimpleGroupResponse-seed#[BEBE5A97A779D553]) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 76434 INFO  
(TEST-QueryResponseTest.testSimpleGroupResponse-seed#[BEBE5A97A779D553]) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 76443 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[BEBE5A97A779D553]) [   
 ] o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 76443 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[BEBE5A97A779D553]) [   
 ] o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 76443 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[BEBE5A97A779D553]) [   
 ] o.a.s.c.SolrResourceLoader new SolrResourceLoader for deduced Solr Home: 
'solr/'
   [junit4]   2> 76443 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[BEBE5A97A779D553]) [   
 ] o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 76443 INFO  
(TEST-QueryResponseTest.testIntervalFacetsResponse-seed#[BEBE5A97A779D553]) [   
 ] o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 76454 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[BEBE5A97A779D553]) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 76454 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[BEBE5A97A779D553]) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 76454 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[BEBE5A97A779D553]) [] 
o.a.s.c.SolrResourceLoader new SolrResourceLoader for deduced Solr Home: 'solr/'
   [junit4]   2> 76454 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[BEBE5A97A779D553]) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 76454 INFO  
(TEST-QueryResponseTest.testGroupResponse-seed#[BEBE5A97A779D553]) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 76461 INFO  
(TEST-QueryResponseTest.testDateFacets-seed#[BEBE5A97A779D553]) [] 

[jira] [Closed] (LUCENE-6467) Simplify Query.equals()

[Paul Elschot (JIRA)]

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

Paul Elschot closed LUCENE-6467.


Thanks.

> Simplify Query.equals()
> ---
>
> Key: LUCENE-6467
> URL: https://issues.apache.org/jira/browse/LUCENE-6467
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Paul Elschot
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6474.patch
>
>
> Remove this == other test in Query.equals().



--
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-6188) solr.ICUFoldingFilterFactory causes NoClassDefFoundError: o/a/l/a/icu/ICUFoldingFilter

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-6188:
--

+1, LGTM, I don't know a lot about classloaders, but AFAICT this works around 
the bug Uwe describes 
[above|https://issues.apache.org/jira/browse/SOLR-6188?focusedCommentId=14039350=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14039350].

> solr.ICUFoldingFilterFactory causes NoClassDefFoundError: 
> o/a/l/a/icu/ICUFoldingFilter
> --
>
> Key: SOLR-6188
> URL: https://issues.apache.org/jira/browse/SOLR-6188
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 4.8.1
>Reporter: Ahmet Arslan
>Assignee: Shawn Heisey
>  Labels: ICUFoldingFilterFactory
> Attachments: SOLR-6188.patch, SOLR-6188.patch, SOLR-6188.patch, 
> SOLR-6188.patch, SOLR-6188.patch, SOLR-6188.patch, SOLR-6188.patch
>
>
> When fully qualified class name is used in schema.xml 
> {{org.apache.lucene.analysis.icu.ICUFoldingFilterFactory}}
> it works. However as documented in confluence and wiki, when 
> {{solr.ICUFoldingFilterFactory}} is used it throws following exception.
> This is true for both released 4.8.1 version and trunk r1604168
> following type works :
> {code:xml}
>  
>   
> 
>  class="org.apache.lucene.analysis.icu.ICUFoldingFilterFactory"/>
>   
> 
> {code}
> this does not : 
> {code:xml}
>  
>   
> 
> 
>   
> 
> {code}
> {noformat}
> 257 [main] ERROR org.apache.solr.core.SolrCore  – Error loading 
> core:java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: 
> org/apache/lucene/analysis/icu/ICUFoldingFilter
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122)
>   at java.util.concurrent.FutureTask.get(FutureTask.java:188)
>   at org.apache.solr.core.CoreContainer.load(CoreContainer.java:301)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:190)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:137)
>   at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:119)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:719)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1252)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:710)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
>   at 
> org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:39)
>   at 
> org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)
>   at 
> org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:494)
>   at 
> org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:141)
>   at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:145)
>   at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:56)
>   at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:609)
>   at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:540)
>   at org.eclipse.jetty.util.Scanner.scan(Scanner.java:403)
>   at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:337)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
>   at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:121)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
>   at 
> org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:555)
>   at 
> org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:230)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
>   at 
> org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:81)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:58)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:96)
>   at org.eclipse.jetty.server.Server.doStart(Server.java:280)
>   at 
> 

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_60) - Build # 5319 - Still Failing!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
Delete action failed!

Stack Trace:
java.lang.AssertionError: Delete action failed!
at 
__randomizedtesting.SeedInfo.seed([5F400653D725521A:4C23343CE64AEBBC]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
at 
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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 

[jira] [Commented] (LUCENE-6305) BooleanQuery.equals should ignore clause order

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6305:
--

Are there still objections to commit this patch in light of the latest comments?

> BooleanQuery.equals should ignore clause order
> --
>
> Key: LUCENE-6305
> URL: https://issues.apache.org/jira/browse/LUCENE-6305
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6305.patch, LUCENE-6305.patch
>
>
> BooleanQuery.equals is sensitive to the order in which clauses have been 
> added. So for instance "+A +B" would be considered different from "+B +A" 
> although it generates the same matches and scores.



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

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

[jira] [Commented] (LUCENE-6305) BooleanQuery.equals should ignore clause order

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on LUCENE-6305:


No objection, but it would be good for the javadoc for BQ and BQ.Builder to 
explicitly state the contract that the order that clauses are added will not 
impact either the results of the query, their order, or the performance of the 
execution of the query - assuming those facts are all true.

> BooleanQuery.equals should ignore clause order
> --
>
> Key: LUCENE-6305
> URL: https://issues.apache.org/jira/browse/LUCENE-6305
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6305.patch, LUCENE-6305.patch
>
>
> BooleanQuery.equals is sensitive to the order in which clauses have been 
> added. So for instance "+A +B" would be considered different from "+B +A" 
> although it generates the same matches and scores.



--
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-8139) Provide a way for the admin UI to utilize managed schema functionality

[Upayavira (JIRA)]

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

Upayavira updated SOLR-8139:

Attachment: add-field-with-errors.png

> Provide a way for the admin UI to utilize managed schema functionality
> --
>
> Key: SOLR-8139
> URL: https://issues.apache.org/jira/browse/SOLR-8139
> Project: Solr
>  Issue Type: Improvement
>  Components: UI
>Reporter: Erick Erickson
>Assignee: Upayavira
> Attachments: add-field-with-errors.png, add-field-with-omit-open.png, 
> add-field.png
>
>
> See the discussion at the related SOLR-8131. The suggestion there is to make 
> managed schema the default in 6.0. To make the new-user experience much 
> smoother in that setup, it would be great if the admin UI had a simple 
> wrapper around the managed schema API.
> It would be a fine thing to have a way of bypassing the whole "find the magic 
> config set, edit it in your favorite editor, figure out how to upload it via 
> zkcli then reload the collection" current paradigm and instead be able to 
> update the schema via the admin UI.
> This should bypass the issues with uploading arbitrary XML to the server that 
> shot down one of the other attempts to edit the schema from the admin UI.
> This is mostly a marker. This could be a significant differentiator between 
> the old and new admin UIs.



--
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-8139) Provide a way for the admin UI to utilize managed schema functionality

[Upayavira (JIRA)]

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

Upayavira updated SOLR-8139:

Attachment: add-field.png

> Provide a way for the admin UI to utilize managed schema functionality
> --
>
> Key: SOLR-8139
> URL: https://issues.apache.org/jira/browse/SOLR-8139
> Project: Solr
>  Issue Type: Improvement
>  Components: UI
>Reporter: Erick Erickson
>Assignee: Upayavira
> Attachments: add-field-with-omit-open.png, add-field.png
>
>
> See the discussion at the related SOLR-8131. The suggestion there is to make 
> managed schema the default in 6.0. To make the new-user experience much 
> smoother in that setup, it would be great if the admin UI had a simple 
> wrapper around the managed schema API.
> It would be a fine thing to have a way of bypassing the whole "find the magic 
> config set, edit it in your favorite editor, figure out how to upload it via 
> zkcli then reload the collection" current paradigm and instead be able to 
> update the schema via the admin UI.
> This should bypass the issues with uploading arbitrary XML to the server that 
> shot down one of the other attempts to edit the schema from the admin UI.
> This is mostly a marker. This could be a significant differentiator between 
> the old and new admin UIs.



--
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-8139) Provide a way for the admin UI to utilize managed schema functionality

[Upayavira (JIRA)]

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

Upayavira updated SOLR-8139:

Attachment: add-field-with-omit-open.png

> Provide a way for the admin UI to utilize managed schema functionality
> --
>
> Key: SOLR-8139
> URL: https://issues.apache.org/jira/browse/SOLR-8139
> Project: Solr
>  Issue Type: Improvement
>  Components: UI
>Reporter: Erick Erickson
>Assignee: Upayavira
> Attachments: add-field-with-omit-open.png, add-field.png
>
>
> See the discussion at the related SOLR-8131. The suggestion there is to make 
> managed schema the default in 6.0. To make the new-user experience much 
> smoother in that setup, it would be great if the admin UI had a simple 
> wrapper around the managed schema API.
> It would be a fine thing to have a way of bypassing the whole "find the magic 
> config set, edit it in your favorite editor, figure out how to upload it via 
> zkcli then reload the collection" current paradigm and instead be able to 
> update the schema via the admin UI.
> This should bypass the issues with uploading arbitrary XML to the server that 
> shot down one of the other attempts to edit the schema from the admin UI.
> This is mostly a marker. This could be a significant differentiator between 
> the old and new admin UIs.



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b83) - Build # 14465 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14465/
Java: 32bit/jdk1.9.0-ea-b83 -client -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 8517 lines...]
[javac] Compiling 874 source files to 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/classes/java
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.8
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/core/ImplicitPlugins.java:102:
 error: reference to NamedList is ambiguous
[javac] return new PluginInfo(SolrRequestHandler.TYPE, m, new 
NamedList<>(singletonMap(DEFAULTS, new NamedList(defaults))),null);
[javac]   ^
[javac]   both constructor NamedList(Entry[]) in 
NamedList and constructor NamedList(Map) in NamedList 
match
[javac]   where T is a type-variable:
[javac] T extends Object declared in class NamedList
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/core/ImplicitPlugins.java:102:
 error: incompatible types: cannot infer type arguments for NamedList<>
[javac] return new PluginInfo(SolrRequestHandler.TYPE, m, new 
NamedList<>(singletonMap(DEFAULTS, new NamedList(defaults))),null);
[javac]^
[javac] reason: no instance(s) of type variable(s) K,V exist so that 
Map conforms to Entry[]
[javac]   where K,V,T are type-variables:
[javac] K extends Object declared in method singletonMap(K,V)
[javac] V extends Object declared in method singletonMap(K,V)
[javac] T extends Object declared in class NamedList
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] Note: Some messages have been simplified; recompile with 
-Xdiags:verbose to get full output
[javac] 2 errors

[...truncated 1 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:719: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:59: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:233: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:516: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:466: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:379: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:509: 
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1944: 
Compile failed; see the compiler error output for details.

Total time: 22 minutes 6 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Updated] (SOLR-8144) solr.xml not found after restarting example node

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-8144:
---
  Priority: Minor  (was: Major)
Issue Type: Improvement  (was: Bug)

FYI, [~varunthacker], [~thelabdude].

> solr.xml not found after restarting example node
> 
>
> Key: SOLR-8144
> URL: https://issues.apache.org/jira/browse/SOLR-8144
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Priority: Minor
>
> Steps to reproduce:
> 1. ./bin/solr start -e cloud -noprompt
> 2. ./bin/solr stop -p 8983
> 2. ./bin/solr start -c -s example/cloud/node1/ -p 8983
> 4. This URL gives an NPE : http://localhost:8983/solr/#/
> Error:
> {noformat}
> org.apache.solr.common.SolrException: Error processing the request. 
> CoreContainer is either not initialized or shutting down.
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:187)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> {noformat}
> From the logs:
> {noformat}
> INFO  - 2015-10-08 09:19:48.141; [   ] org.apache.solr.core.SolrXmlConfig; 
> Loading container configuration from /home/ishan/code/lucene-solr-svn
> /solr/example/cloud/node1/solr.xml
> ERROR - 2015-10-08 09:19:48.143; [   ] 
> org.apache.solr.servlet.SolrDispatchFilter; Could not start Solr. Check 
> solr/home property and the logs
> ERROR - 2015-10-08 09:19:48.158; [   ] org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.SolrException: solr.xml does not exist 
> in /home/ishan/code/lucene-solr-svn/solr/example/cloud/node1/solr.xml cannot 
> start Solr
> at org.apache.solr.core.SolrXmlConfig.fromFile(SolrXmlConfig.java:108)
> at 
> org.apache.solr.core.SolrXmlConfig.fromSolrHome(SolrXmlConfig.java:140)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.loadNodeConfig(SolrDispatchFilter.java:162)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:130)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:109)
> at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> {noformat}
> It is looking for a solr.xml in 
> {{/home/ishan/code/lucene-solr-svn/solr/example/cloud/node1/solr.xml}} but it 
> exists in 
> {{/home/ishan/code/lucene-solr-svn/solr/example/cloud/node1/solr/solr.xml}}
> Preliminarily, it looks to me like a start script issue.



--
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-8144) solr.xml not found after restarting example node

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya reopened SOLR-8144:


These kinds of mistakes by user could be common. It might be nice for the 
script to detect such errors and use the proper directory, and possibly throw a 
warning to the same effect. Reopening this to tackle this automatic detection 
and handling of the solr directory.

> solr.xml not found after restarting example node
> 
>
> Key: SOLR-8144
> URL: https://issues.apache.org/jira/browse/SOLR-8144
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>
> Steps to reproduce:
> 1. ./bin/solr start -e cloud -noprompt
> 2. ./bin/solr stop -p 8983
> 2. ./bin/solr start -c -s example/cloud/node1/ -p 8983
> 4. This URL gives an NPE : http://localhost:8983/solr/#/
> Error:
> {noformat}
> org.apache.solr.common.SolrException: Error processing the request. 
> CoreContainer is either not initialized or shutting down.
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:187)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> {noformat}
> From the logs:
> {noformat}
> INFO  - 2015-10-08 09:19:48.141; [   ] org.apache.solr.core.SolrXmlConfig; 
> Loading container configuration from /home/ishan/code/lucene-solr-svn
> /solr/example/cloud/node1/solr.xml
> ERROR - 2015-10-08 09:19:48.143; [   ] 
> org.apache.solr.servlet.SolrDispatchFilter; Could not start Solr. Check 
> solr/home property and the logs
> ERROR - 2015-10-08 09:19:48.158; [   ] org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.SolrException: solr.xml does not exist 
> in /home/ishan/code/lucene-solr-svn/solr/example/cloud/node1/solr.xml cannot 
> start Solr
> at org.apache.solr.core.SolrXmlConfig.fromFile(SolrXmlConfig.java:108)
> at 
> org.apache.solr.core.SolrXmlConfig.fromSolrHome(SolrXmlConfig.java:140)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.loadNodeConfig(SolrDispatchFilter.java:162)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:130)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:109)
> at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> {noformat}
> It is looking for a solr.xml in 
> {{/home/ishan/code/lucene-solr-svn/solr/example/cloud/node1/solr.xml}} but it 
> exists in 
> {{/home/ishan/code/lucene-solr-svn/solr/example/cloud/node1/solr/solr.xml}}
> Preliminarily, it looks to me like a start script issue.



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

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

[jira] [Commented] (LUCENE-6821) TermQuery's constructors should clone the incoming term

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6821:
--

I like how the patch makes things simpler. I'll wait a bit before committing to 
give other people a chance to comment. Can you also remove the explicit cloning 
that we added in LUCENE-6435?

> TermQuery's constructors should clone the incoming term
> ---
>
> Key: LUCENE-6821
> URL: https://issues.apache.org/jira/browse/LUCENE-6821
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6821.patch, LUCENE-6821.patch
>
>
> This is a follow-up of LUCENE-6435: the bug stems from the fact that you can 
> build term queries out of shared BytesRef objects (such as the ones returned 
> by TermsEnum.next), which is a bit trappy. If TermQuery's constructors would 
> clone the incoming term, we wouldn't have this trap.



--
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-5944) Support updates of numeric DocValues

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-5944:


bq. What would cause the second update to 'doc1' apply before the NUMERIC 
update of 'dvField' of 'doc1'?

The fundamental issue is this: the leader can forward updates to a replica over 
different threads / connections, and can be handled my multiple threads on the 
replica side.  This leads to many opportunities for update reorders.

Solr does currently detect (via versioning) and handle all of the reorder cases 
today.  When a document is sent to a replica, the whole thing is sent.  If a 
replica gets an older version of a document, it can simply drop it.  This type 
of handling doesn't work when you're talking about re-ordered partial / 
in-place updates... just dropping old versions doesn't work.


> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



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

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

Re: [JENKINS-EA] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b83) - Build # 14175 - Still Failing!

[Adrien Grand]

I'm fixing. Sorry for the noise I don't know how I let it through!

Le ven. 9 oct. 2015 à 12:24, Policeman Jenkins Server 
a écrit :

> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14175/
> Java: 32bit/jdk1.9.0-ea-b83 -client -XX:+UseSerialGC
>
> No tests ran.
>
> Build Log:
> [...truncated 245 lines...]
> [javac] Compiling 727 source files to
> /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/classes/java
> [javac]
> /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/core/src/java/org/apache/lucene/search/Query.java:121:
> error: ';' expected
> [javac] return Float.floatToIntBits(boost) ==
> Float.floatToIntBits(other.boost)
> [javac]
> ^
> [javac] 1 error
>
> BUILD FAILED
> /home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:785: The following
> error occurred while executing this line:
> /home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:729: The following
> error occurred while executing this line:
> /home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:59: The following
> error occurred while executing this line:
> /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build.xml:50: The
> following error occurred while executing this line:
> /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:526:
> The following error occurred while executing this line:
> /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:1964:
> Compile failed; see the compiler error output for details.
>
> Total time: 2 seconds
> Build step 'Invoke Ant' marked build as failure
> Archiving artifacts
> [WARNINGS] Skipping publisher since build result is FAILURE
> Recording test results
> ERROR: Publisher 'Publish JUnit test result report' failed: No test report
> files were found. Configuration error?
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6467) Simplify Query.equals()

[ASF subversion and git services (JIRA)]

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

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

Commit 1707690 from [~jpountz] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1707690 ]

LUCENE-6467: Fix compilation.

> Simplify Query.equals()
> ---
>
> Key: LUCENE-6467
> URL: https://issues.apache.org/jira/browse/LUCENE-6467
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Paul Elschot
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6474.patch
>
>
> Remove this == other test in Query.equals().



--
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-8149) Core Selector -> Plugins / Stats - active item is not highlighted

[Labuzov Dmitriy (JIRA)]

Labuzov Dmitriy created SOLR-8149:
-

 Summary: Core Selector -> Plugins / Stats - active item is not 
highlighted
 Key: SOLR-8149
 URL: https://issues.apache.org/jira/browse/SOLR-8149
 Project: Solr
  Issue Type: Bug
  Components: UI
Affects Versions: 5.3.1
Reporter: Labuzov Dmitriy
Priority: Trivial


Angular UI version:
Select a core in 'Core Selector' then go to 'Plugins / Stats', then select any 
item (ex., CACHE) - active item is not highlighted (it does in Original UI).



--
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-8149) Core Selector -> Plugins / Stats - active item is not highlighted

[Labuzov Dmitriy (JIRA)]

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

Labuzov Dmitriy updated SOLR-8149:
--
Attachment: SOLR-8149.patch

I suggest the following changes to fix that.

> Core Selector -> Plugins / Stats - active item is not highlighted
> -
>
> Key: SOLR-8149
> URL: https://issues.apache.org/jira/browse/SOLR-8149
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 5.3.1
>Reporter: Labuzov Dmitriy
>Priority: Trivial
> Attachments: SOLR-8149.patch
>
>
> Angular UI version:
> Select a core in 'Core Selector' then go to 'Plugins / Stats', then select 
> any item (ex., CACHE) - active item is not highlighted (it does in Original 
> UI).



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

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

[jira] [Updated] (LUCENE-6305) BooleanQuery.equals should ignore clause order

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-6305:
-
Attachment: LUCENE-6305.patch

Good call Jack.

bq.  the order that clauses are added will not impact either the results of the 
query, their order,

This is true.

bq. or the performance of the execution of the query

This is mostly true today and should be completely true once LUCENE-6276 is in.

Here is a new patch with improved javadocs. I also improved equals to ignore 
duplicates for FILTER and MUST_NOT clauses since they don't matter, and made 
the hashCode() cached.

> BooleanQuery.equals should ignore clause order
> --
>
> Key: LUCENE-6305
> URL: https://issues.apache.org/jira/browse/LUCENE-6305
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6305.patch, LUCENE-6305.patch, LUCENE-6305.patch
>
>
> BooleanQuery.equals is sensitive to the order in which clauses have been 
> added. So for instance "+A +B" would be considered different from "+B +A" 
> although it generates the same matches and scores.



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14179/
Java: 64bit/jdk1.8.0_60 -XX:+UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.BasicAuthIntegrationTest

Error Message:
91 threads leaked from SUITE scope at 
org.apache.solr.security.BasicAuthIntegrationTest: 1) Thread[id=1248, 
name=qtp288600901-1248-selector-ServerConnectorManager@3260a6a1/0, 
state=RUNNABLE, group=TGRP-BasicAuthIntegrationTest] 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.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:600)
 at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:549)
 at 
org.eclipse.jetty.util.thread.NonBlockingThread.run(NonBlockingThread.java:52)  
   at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) 
at java.lang.Thread.run(Thread.java:745)2) Thread[id=1317, 
name=zkCallback-134-thread-1, state=TIMED_WAITING, 
group=TGRP-BasicAuthIntegrationTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)3) Thread[id=1349, 
name=zkCallback-133-thread-3, state=TIMED_WAITING, 
group=TGRP-BasicAuthIntegrationTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)4) Thread[id=1274, 
name=qtp288600901-1274, state=TIMED_WAITING, 
group=TGRP-BasicAuthIntegrationTest] 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 
org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:389) 
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:531)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool.access$700(QueuedThreadPool.java:47)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:590) 
at java.lang.Thread.run(Thread.java:745)5) Thread[id=1257, 
name=qtp577362013-1257-acceptor-0@fa0e965-ServerConnector@4706267e{HTTP/1.1}{127.0.0.1:46355},
 state=RUNNABLE, group=TGRP-BasicAuthIntegrationTest] at 
sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) at 
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422) 
at 
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250) 
at 
org.eclipse.jetty.server.ServerConnector.accept(ServerConnector.java:377)   
  at 
org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:500)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) 
at java.lang.Thread.run(Thread.java:745)6) Thread[id=1352, 
name=zkCallback-134-thread-3, state=TIMED_WAITING, 
group=TGRP-BasicAuthIntegrationTest] at sun.misc.Unsafe.park(Native 
Method) at 

[JENKINS] Lucene-Solr-5.x-Solaris (multiarch/jdk1.7.0) - Build # 111 - Still Failing!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.ConnectionManagerTest.testLikelyExpired

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:56310 within 3 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:56310 within 3 ms
at 
__randomizedtesting.SeedInfo.seed([9CA6CEF09264B7AD:B8D36CA8B2189392]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:181)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:115)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:110)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:97)
at 
org.apache.solr.cloud.AbstractZkTestCase.tryCleanPath(AbstractZkTestCase.java:183)
at 
org.apache.solr.cloud.AbstractZkTestCase.tryCleanSolrZkNode(AbstractZkTestCase.java:179)
at 
org.apache.solr.cloud.ConnectionManagerTest.testLikelyExpired(ConnectionManagerTest.java:77)
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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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 

[jira] [Commented] (LUCENE-6821) TermQuery's constructors should clone the incoming term

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-6821:
--

bq. Can you also remove the explicit cloning that we added in LUCENE-6435?
I tried, but then a test fails.
Perhaps this is because a BytesRef is passed ClassificationResult there.

> TermQuery's constructors should clone the incoming term
> ---
>
> Key: LUCENE-6821
> URL: https://issues.apache.org/jira/browse/LUCENE-6821
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6821.patch, LUCENE-6821.patch
>
>
> This is a follow-up of LUCENE-6435: the bug stems from the fact that you can 
> build term queries out of shared BytesRef objects (such as the ones returned 
> by TermsEnum.next), which is a bit trappy. If TermQuery's constructors would 
> clone the incoming term, we wouldn't have this trap.



--
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 # 2789 - Still Failing!

[Policeman Jenkins Server]

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

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([6027C6388493B58F]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:467)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:233)
at sun.reflect.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:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java: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:367)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=1830, name=searcherExecutor-687-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=1830, name=searcherExecutor-687-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([6027C6388493B58F]:0)


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

Error Message:
There 

[jira] [Commented] (SOLR-6188) solr.ICUFoldingFilterFactory causes NoClassDefFoundError: o/a/l/a/icu/ICUFoldingFilter

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-6188:


I was sent four direct messages from Policeman Jenkins.  The failures did not 
look like they were caused by my commit, and one of them was the failure that I 
described above.  I would appreciate a review before I backport to 5x.

> solr.ICUFoldingFilterFactory causes NoClassDefFoundError: 
> o/a/l/a/icu/ICUFoldingFilter
> --
>
> Key: SOLR-6188
> URL: https://issues.apache.org/jira/browse/SOLR-6188
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 4.8.1
>Reporter: Ahmet Arslan
>Assignee: Shawn Heisey
>  Labels: ICUFoldingFilterFactory
> Attachments: SOLR-6188.patch, SOLR-6188.patch, SOLR-6188.patch, 
> SOLR-6188.patch, SOLR-6188.patch, SOLR-6188.patch, SOLR-6188.patch
>
>
> When fully qualified class name is used in schema.xml 
> {{org.apache.lucene.analysis.icu.ICUFoldingFilterFactory}}
> it works. However as documented in confluence and wiki, when 
> {{solr.ICUFoldingFilterFactory}} is used it throws following exception.
> This is true for both released 4.8.1 version and trunk r1604168
> following type works :
> {code:xml}
>  
>   
> 
>  class="org.apache.lucene.analysis.icu.ICUFoldingFilterFactory"/>
>   
> 
> {code}
> this does not : 
> {code:xml}
>  
>   
> 
> 
>   
> 
> {code}
> {noformat}
> 257 [main] ERROR org.apache.solr.core.SolrCore  – Error loading 
> core:java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: 
> org/apache/lucene/analysis/icu/ICUFoldingFilter
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122)
>   at java.util.concurrent.FutureTask.get(FutureTask.java:188)
>   at org.apache.solr.core.CoreContainer.load(CoreContainer.java:301)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:190)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:137)
>   at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:119)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:719)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1252)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:710)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
>   at 
> org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:39)
>   at 
> org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)
>   at 
> org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:494)
>   at 
> org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:141)
>   at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:145)
>   at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:56)
>   at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:609)
>   at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:540)
>   at org.eclipse.jetty.util.Scanner.scan(Scanner.java:403)
>   at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:337)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
>   at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:121)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
>   at 
> org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:555)
>   at 
> org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:230)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
>   at 
> org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:81)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:58)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:96)
>   at org.eclipse.jetty.server.Server.doStart(Server.java:280)
>   at 
> 

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

[Policeman Jenkins Server]

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

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 1) Thread[id=4060, 
name=apacheds, state=WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] 
at java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)2) Thread[id=4064, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] 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:746)3) Thread[id=4063, 
name=groupCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] 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:746)4) Thread[id=4062, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] 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:746)5) Thread[id=4061, 
name=ou=system.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] 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:746)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 
   1) Thread[id=4060, name=apacheds, state=WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:516)
at java.util.TimerThread.mainLoop(Timer.java:526)
at java.util.TimerThread.run(Timer.java:505)
   2) Thread[id=4064, name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt]
   

[jira] [Commented] (LUCENE-6301) Deprecate Filter

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-6301:
--

+1   Nice Adrien!  Looks like this was a fair amount of work.  I agree on 
moving the abstractions to Solr.  Wether or not it remains in Solr shouldn't 
hold up this.

> Deprecate Filter
> 
>
> Key: LUCENE-6301
> URL: https://issues.apache.org/jira/browse/LUCENE-6301
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Fix For: 5.2, Trunk
>
> Attachments: LUCENE-6301.patch, LUCENE-6301.patch
>
>
> It will still take time to completely remove Filter, but I think we should 
> start deprecating it now to state our intention and encourage users to move 
> to queries as soon as possible?



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