[jira] [Updated] (SOLR-8756) Need 4 config "zkDigestUsername"/"zkDigestPassword"/ solr.xml

2016-02-28 Thread Forest Soup (JIRA)

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

Forest Soup updated SOLR-8756:
--
Summary: Need 4 config "zkDigestUsername"/"zkDigestPassword"/  solr.xml  
(was: Need config "zkDigestUsername" and "zkDigestPassword" in 
/solr.xml)

> Need 4 config "zkDigestUsername"/"zkDigestPassword"/  solr.xml
> --
>
> Key: SOLR-8756
> URL: https://issues.apache.org/jira/browse/SOLR-8756
> Project: Solr
>  Issue Type: Bug
>  Components: security, SolrCloud
>Affects Versions: 5.3.1
> Environment: Linux 64bit
>Reporter: Forest Soup
>  Labels: security
>
> Need 4 config in /solr.xml instead of -D parameter in solr.in.sh.
> like below:
> 
>   
> zkusername
> zkpassword
> zkreadonlyusername
>  name="zkDigestReadonlyUsername">readonlypassword
> ...
> Otherwise, any user can use the linux "ps" command showing the full command 
> line including the plain text zookeeper username and password. If we use file 
> store them, we can control the access of the file not to leak the 
> username/password.



--
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-8756) Need 4 config "zkDigestUsername"/"zkDigestPassword"/"zkDigestReadonlyUsername"/"zkDigestReadonlyUsername" in solr.xml

2016-02-28 Thread Forest Soup (JIRA)

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

Forest Soup updated SOLR-8756:
--
Summary: Need 4 config 
"zkDigestUsername"/"zkDigestPassword"/"zkDigestReadonlyUsername"/"zkDigestReadonlyUsername"
 in solr.xml  (was: Need 4 config 
"zkDigestUsername"/"zkDigestPassword"/"zkDigestReadonlyUsername"/  solr.xml)

> Need 4 config 
> "zkDigestUsername"/"zkDigestPassword"/"zkDigestReadonlyUsername"/"zkDigestReadonlyUsername"
>  in solr.xml
> -
>
> Key: SOLR-8756
> URL: https://issues.apache.org/jira/browse/SOLR-8756
> Project: Solr
>  Issue Type: Bug
>  Components: security, SolrCloud
>Affects Versions: 5.3.1
> Environment: Linux 64bit
>Reporter: Forest Soup
>  Labels: security
>
> Need 4 config in /solr.xml instead of -D parameter in solr.in.sh.
> like below:
> 
>   
> zkusername
> zkpassword
> zkreadonlyusername
>  name="zkDigestReadonlyUsername">readonlypassword
> ...
> Otherwise, any user can use the linux "ps" command showing the full command 
> line including the plain text zookeeper username and password. If we use file 
> store them, we can control the access of the file not to leak the 
> username/password.



--
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-8756) Need 4 config "zkDigestUsername"/"zkDigestPassword"/"zkDigestReadonlyUsername"/ solr.xml

2016-02-28 Thread Forest Soup (JIRA)

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

Forest Soup updated SOLR-8756:
--
Summary: Need 4 config 
"zkDigestUsername"/"zkDigestPassword"/"zkDigestReadonlyUsername"/  solr.xml  
(was: Need 4 config "zkDigestUsername"/"zkDigestPassword"/  solr.xml)

> Need 4 config 
> "zkDigestUsername"/"zkDigestPassword"/"zkDigestReadonlyUsername"/  solr.xml
> -
>
> Key: SOLR-8756
> URL: https://issues.apache.org/jira/browse/SOLR-8756
> Project: Solr
>  Issue Type: Bug
>  Components: security, SolrCloud
>Affects Versions: 5.3.1
> Environment: Linux 64bit
>Reporter: Forest Soup
>  Labels: security
>
> Need 4 config in /solr.xml instead of -D parameter in solr.in.sh.
> like below:
> 
>   
> zkusername
> zkpassword
> zkreadonlyusername
>  name="zkDigestReadonlyUsername">readonlypassword
> ...
> Otherwise, any user can use the linux "ps" command showing the full command 
> line including the plain text zookeeper username and password. If we use file 
> store them, we can control the access of the file not to leak the 
> username/password.



--
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-8756) Need config "zkDigestUsername" and "zkDigestPassword" in /solr.xml

2016-02-28 Thread Forest Soup (JIRA)
Forest Soup created SOLR-8756:
-

 Summary: Need config "zkDigestUsername" and "zkDigestPassword" in 
/solr.xml
 Key: SOLR-8756
 URL: https://issues.apache.org/jira/browse/SOLR-8756
 Project: Solr
  Issue Type: Bug
  Components: security, SolrCloud
Affects Versions: 5.3.1
 Environment: Linux 64bit
Reporter: Forest Soup


Need 2 config in /solr.xml instead of -D parameter in solr.in.sh.

like below:

  
zkusername
zkpassword
zkreadonlyusername
readonlypassword
...

Otherwise, any user can use the linux "ps" command showing the full command 
line including the plain text zookeeper username and password. If we use file 
store them, we can control the access of the file not to leak the 
username/password.



--
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-8756) Need config "zkDigestUsername" and "zkDigestPassword" in /solr.xml

2016-02-28 Thread Forest Soup (JIRA)

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

Forest Soup updated SOLR-8756:
--
Description: 
Need 4 config in /solr.xml instead of -D parameter in solr.in.sh.

like below:

  
zkusername
zkpassword
zkreadonlyusername
readonlypassword
...

Otherwise, any user can use the linux "ps" command showing the full command 
line including the plain text zookeeper username and password. If we use file 
store them, we can control the access of the file not to leak the 
username/password.

  was:
Need 2 config in /solr.xml instead of -D parameter in solr.in.sh.

like below:

  
zkusername
zkpassword
zkreadonlyusername
readonlypassword
...

Otherwise, any user can use the linux "ps" command showing the full command 
line including the plain text zookeeper username and password. If we use file 
store them, we can control the access of the file not to leak the 
username/password.


> Need config "zkDigestUsername" and "zkDigestPassword" in /solr.xml
> 
>
> Key: SOLR-8756
> URL: https://issues.apache.org/jira/browse/SOLR-8756
> Project: Solr
>  Issue Type: Bug
>  Components: security, SolrCloud
>Affects Versions: 5.3.1
> Environment: Linux 64bit
>Reporter: Forest Soup
>  Labels: security
>
> Need 4 config in /solr.xml instead of -D parameter in solr.in.sh.
> like below:
> 
>   
> zkusername
> zkpassword
> zkreadonlyusername
>  name="zkDigestReadonlyUsername">readonlypassword
> ...
> Otherwise, any user can use the linux "ps" command showing the full command 
> line including the plain text zookeeper username and password. If we use file 
> store them, we can control the access of the file not to leak the 
> username/password.



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

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



[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk-9-ea+107) - Build # 16043 - Still Failing!

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16043/
Java: 64bit/jdk-9-ea+107 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.lucene.util.automaton.TestOperations.testIsFinite

Error Message:
6

Stack Trace:
java.lang.ArrayIndexOutOfBoundsException: 6
at 
__randomizedtesting.SeedInfo.seed([BBE64C3C1562001B:9BDFBD2C592BDF8D]:0)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:524)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomSingleAutomaton(AutomatonTestUtil.java:262)
at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomAutomaton(AutomatonTestUtil.java:277)
at 
org.apache.lucene.util.automaton.TestOperations.testIsFinite(TestOperations.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:804)




Build Log:
[...truncated 1519 lines...]
   [junit4] Suite: org.apache.lucene.util.automaton.TestOperations
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestOperations 
-Dtests.method=testIsFinite 

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

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/160/
Java: 32bit/jdk-9-ea+107 -server -XX:+UseConcMarkSweepGC

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=2351, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)2) Thread[id=2355, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)3) Thread[id=2354, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)4) Thread[id=2352, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)5) Thread[id=2353, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+107) - Build # 16042 - Failure!

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16042/
Java: 32bit/jdk-9-ea+107 -server -XX:+UseConcMarkSweepGC

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=11756, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)2) Thread[id=11753, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)3) Thread[id=11757, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)4) Thread[id=11755, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)5) Thread[id=11754, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=11756, name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at jdk.internal.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
at 

[jira] [Updated] (LUCENE-7054) add newDistanceQuery to sandbox LatLonPoint

2016-02-28 Thread Robert Muir (JIRA)

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

Robert Muir updated LUCENE-7054:

Attachment: LUCENE-7054.patch

initial patch.

I hooked in the new query into the existing test infra 
(TestLatLonPointQueries/BaseGeoPointTestCase) but also added a conceptually 
simpler random test to TestLatLonPoint that doesn't have any 
leniency/tolerance/deltas. 

I tried to keep it simple and free of things like floating point error, to keep 
testing exact.

We don't do any fancy geometric stuff like computing whether circles intersect 
with rectangles (there are utility methods here, but i did not have such luck 
with this approach). 

tests seem to pass under beasting... no benchmarking whatsoever though.

> add newDistanceQuery to sandbox LatLonPoint
> ---
>
> Key: LUCENE-7054
> URL: https://issues.apache.org/jira/browse/LUCENE-7054
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7054.patch
>
>
> This field is currently missing a distance radius query: this is a common use 
> case.



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

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



[jira] [Created] (LUCENE-7054) add newDistanceQuery to sandbox LatLonPoint

2016-02-28 Thread Robert Muir (JIRA)
Robert Muir created LUCENE-7054:
---

 Summary: add newDistanceQuery to sandbox LatLonPoint
 Key: LUCENE-7054
 URL: https://issues.apache.org/jira/browse/LUCENE-7054
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Robert Muir


This field is currently missing a distance radius query: this is a common use 
case.



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

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



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

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/159/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest: 1) Thread[id=9350, 
name=TEST-CollectionsAPIDistributedZkTest.test-seed#[30E8E90848FCDDCA]-EventThread,
 state=WAITING, group=TGRP-CollectionsAPIDistributedZkTest] 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 org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:494)
2) Thread[id=9645, name=zkCallback-1377-thread-2, state=TIMED_WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] 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=9349, 
name=TEST-CollectionsAPIDistributedZkTest.test-seed#[30E8E90848FCDDCA]-SendThread(127.0.0.1:51155),
 state=TIMED_WAITING, group=TGRP-CollectionsAPIDistributedZkTest] at 
java.lang.Thread.sleep(Native Method) at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:101)
 at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:940)
 at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1003)
4) Thread[id=9351, name=zkCallback-1377-thread-1, state=TIMED_WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] 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)5) Thread[id=9646, 
name=zkCallback-1377-thread-3, state=TIMED_WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] 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)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.CollectionsAPIDistributedZkTest: 
   1) Thread[id=9350, 
name=TEST-CollectionsAPIDistributedZkTest.test-seed#[30E8E90848FCDDCA]-EventThread,
 state=WAITING, group=TGRP-CollectionsAPIDistributedZkTest]
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 org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:494)
   2) Thread[id=9645, name=zkCallback-1377-thread-2, state=TIMED_WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest]
at sun.misc.Unsafe.park(Native Method)
at 

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

2016-02-28 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-mmap-Java8/10/

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

Error Message:
Index: 0, Size: 0

Stack Trace:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at 
__randomizedtesting.SeedInfo.seed([FAD2C302B27433A0:DA12D5A749C9C46]:0)
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1241)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
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:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([FAD2C302B27433A0]:0)


FAILED:  

[JENKINS] Lucene-Solr-5.5-Linux (32bit/jdk1.7.0_80) - Build # 158 - Failure!

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/158/
Java: 32bit/jdk1.7.0_80 -client -XX:+UseSerialGC

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

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

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




Build Log:
[...truncated 11472 lines...]
   [junit4] Suite: org.apache.solr.handler.TestSolrConfigHandlerCloud
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/solr-core/test/J2/temp/solr.handler.TestSolrConfigHandlerCloud_7108E98EF48A1E55-001/init-core-data-001
   [junit4]   2> 1108075 INFO  
(SUITE-TestSolrConfigHandlerCloud-seed#[7108E98EF48A1E55]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false)
   [junit4]   2> 1108075 INFO  
(SUITE-TestSolrConfigHandlerCloud-seed#[7108E98EF48A1E55]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /fze/
   [junit4]   2> 1108078 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[7108E98EF48A1E55]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1108078 INFO  (Thread-2998) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1108078 INFO  (Thread-2998) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1108178 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[7108E98EF48A1E55]) [] 
o.a.s.c.ZkTestServer start zk server on port:35329
   [junit4]   2> 1108179 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[7108E98EF48A1E55]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1108179 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[7108E98EF48A1E55]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1108181 INFO  (zkCallback-1989-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@34e914 name:ZooKeeperConnection 
Watcher:127.0.0.1:35329 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2> 1108181 INFO  

[jira] [Commented] (SOLR-8755) Add test cases for org.apache.solr.parser.TokenMgrError

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

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

ASF GitHub Bot commented on SOLR-8755:
--

GitHub user bvanalderweireldt opened a pull request:

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

SOLR-8755 Add test cases for org.apache.solr.parser.TokenMgrError



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

$ git pull https://github.com/bvanalderweireldt/lucene-solr SOLR-8755

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

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

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

This closes #18


commit 822b4c84bafe6702a9a7569ac50d9b723bb3f96a
Author: bvanalderweireldt 
Date:   2016-02-29T02:05:36Z

SOLR-8755 Add test cases for org.apache.solr.parser.TokenMgrError




> Add test cases for org.apache.solr.parser.TokenMgrError
> ---
>
> Key: SOLR-8755
> URL: https://issues.apache.org/jira/browse/SOLR-8755
> Project: Solr
>  Issue Type: Test
>Affects Versions: master
>Reporter: Benoit Vanalderweireldt
>Priority: Trivial
>  Labels: new, newbie, newdev
> Fix For: master
>
>
> Add test cases for org.apache.solr.parser.TokenMgrError



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

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



[GitHub] lucene-solr pull request: SOLR-8755 Add test cases for org.apache....

2016-02-28 Thread bvanalderweireldt
GitHub user bvanalderweireldt opened a pull request:

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

SOLR-8755 Add test cases for org.apache.solr.parser.TokenMgrError



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

$ git pull https://github.com/bvanalderweireldt/lucene-solr SOLR-8755

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

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

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

This closes #18


commit 822b4c84bafe6702a9a7569ac50d9b723bb3f96a
Author: bvanalderweireldt 
Date:   2016-02-29T02:05:36Z

SOLR-8755 Add test cases for org.apache.solr.parser.TokenMgrError




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

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



[jira] [Created] (SOLR-8755) Add test cases for org.apache.solr.parser.TokenMgrError

2016-02-28 Thread Benoit Vanalderweireldt (JIRA)
Benoit Vanalderweireldt created SOLR-8755:
-

 Summary: Add test cases for org.apache.solr.parser.TokenMgrError
 Key: SOLR-8755
 URL: https://issues.apache.org/jira/browse/SOLR-8755
 Project: Solr
  Issue Type: Test
Affects Versions: master
Reporter: Benoit Vanalderweireldt
Priority: Trivial
 Fix For: master


Add test cases for org.apache.solr.parser.TokenMgrError



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

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



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

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Solaris/20/
Java: multiarch/jdk1.7.0 -d32 -server -XX:+UseParallelGC

No tests ran.

Build Log:
[...truncated 36 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: 
org.eclipse.jgit.api.errors.TransportException: Connection reset
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:639)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to Solaris VBOX(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
at hudson.remoting.Channel.call(Channel.java:781)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor544.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at com.sun.proxy.$Proxy51.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:764)
... 11 more
Caused by: org.eclipse.jgit.api.errors.TransportException: Connection reset
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:637)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.eclipse.jgit.errors.TransportException: Connection reset
at 
org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefs(BasePackConnection.java:182)
at 
org.eclipse.jgit.transport.TransportGitAnon$TcpFetchConnection.(TransportGitAnon.java:194)
at 
org.eclipse.jgit.transport.TransportGitAnon.openFetch(TransportGitAnon.java:120)
at 
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
at 
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
... 11 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:209)
at 

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

2016-02-28 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/904/

1 tests failed.
FAILED:  org.apache.solr.spelling.SpellCheckCollatorTest.testEstimatedHitCounts

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([5F94ECF15EF2114D:6E2F52C4FBCD019D]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:764)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:731)
at 
org.apache.solr.spelling.SpellCheckCollatorTest.testEstimatedHitCounts(SpellCheckCollatorTest.java:561)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//lst[@name='spellcheck']/lst[@name='collations']/lst[@name='collation']/int[@name='hits'
 and 6 <= . and . <= 10]
xml response was: 

0121918everyotherteststop:everyother12everyother


request 

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

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

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

ASF GitHub Bot commented on SOLR-7516:
--

GitHub user bvanalderweireldt opened a pull request:

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

SOLR-7516 add asserts and Improve Javadoc comments (patch from gerlow…

add asserts and Improve Javadoc comments (patch from gerlowskija)

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

$ git pull https://github.com/bvanalderweireldt/lucene-solr SOLR-7516

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

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

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

This closes #17


commit 59ea719566a6df47309a1696af3629a545f17d24
Author: bvanalderweireldt 
Date:   2016-02-29T00:09:57Z

SOLR-7516 add asserts and Improve Javadoc comments (patch from gerlowskija)




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



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

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



[GitHub] lucene-solr pull request: SOLR-7516 add asserts and Improve Javado...

2016-02-28 Thread bvanalderweireldt
GitHub user bvanalderweireldt opened a pull request:

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

SOLR-7516 add asserts and Improve Javadoc comments (patch from gerlow…

add asserts and Improve Javadoc comments (patch from gerlowskija)

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

$ git pull https://github.com/bvanalderweireldt/lucene-solr SOLR-7516

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

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

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

This closes #17


commit 59ea719566a6df47309a1696af3629a545f17d24
Author: bvanalderweireldt 
Date:   2016-02-29T00:09:57Z

SOLR-7516 add asserts and Improve Javadoc comments (patch from gerlowskija)




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

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



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

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16039/
Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
Captured an uncaught exception in thread: Thread[id=6930, 
name=testExecutor-3206-thread-5, state=RUNNABLE, 
group=TGRP-UnloadDistributedZkTest]

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




Build Log:
[...truncated 11200 lines...]
   [junit4] Suite: org.apache.solr.cloud.UnloadDistributedZkTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.UnloadDistributedZkTest_217AA90A440E829C-001/init-core-data-001
   [junit4]   2> 727054 INFO  
(SUITE-UnloadDistributedZkTest-seed#[217AA90A440E829C]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: 
/ojaa/px
   [junit4]   2> 727055 INFO  
(TEST-UnloadDistributedZkTest.test-seed#[217AA90A440E829C]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 727056 INFO  (Thread-2412) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 727056 INFO  (Thread-2412) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   

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

2016-02-28 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/902/

1 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  'X val' for path 'x' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{"wt":"json"},   
"context":{ "webapp":"", "path":"/test1", "httpMethod":"GET"},   
"class":"org.apache.solr.core.BlobStoreTestRequestHandler",   "x":null}

Stack Trace:
java.lang.AssertionError: Could not get expected value  'X val' for path 'x' 
full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"",
"path":"/test1",
"httpMethod":"GET"},
  "class":"org.apache.solr.core.BlobStoreTestRequestHandler",
  "x":null}
at 
__randomizedtesting.SeedInfo.seed([946C9A8628778FFF:4C21B7D1DFAA2A5F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:458)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:238)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)

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

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/3118/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

18 tests failed.
FAILED:  org.apache.solr.TestSolrCoreProperties.testSimple

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:56344/solr/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:56344/solr/collection1
at 
__randomizedtesting.SeedInfo.seed([E587B8B5C166CDD4:DD349C4BE6951905]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:591)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.TestSolrCoreProperties.testSimple(TestSolrCoreProperties.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Commented] (SOLR-8713) New UI points to the wiki for Query Syntax instead of the Reference Guide

2016-02-28 Thread Upayavira (JIRA)

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

Upayavira commented on SOLR-8713:
-

It would be great to have online, per release snapshots of the wiki, but in 
lieu of that, this patch looks good to me.

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



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

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



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

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16038/
Java: 32bit/jdk-9-ea+107 -server -XX:+UseConcMarkSweepGC

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

Error Message:
Captured an uncaught exception in thread: Thread[id=5503, 
name=testExecutor-2432-thread-8, state=RUNNABLE, 
group=TGRP-UnloadDistributedZkTest]

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




Build Log:
[...truncated 16 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at 

[jira] [Commented] (SOLR-8722) Don't force a full ZkStateReader refresh on every Overseer operation

2016-02-28 Thread Scott Blum (JIRA)

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

Scott Blum commented on SOLR-8722:
--

In that case, should we land this patch as-is and then come back with a more 
holistic answer for async failures?

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



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

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



[jira] [Assigned] (SOLR-8438) fromIndex= param for [subquery ] DocTransformer

2016-02-28 Thread Mikhail Khludnev (JIRA)

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

Mikhail Khludnev reassigned SOLR-8438:
--

Assignee: Mikhail Khludnev

> fromIndex= param for [subquery ] DocTransformer 
> 
>
> Key: SOLR-8438
> URL: https://issues.apache.org/jira/browse/SOLR-8438
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>




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

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



[jira] [Assigned] (SOLR-8208) DocTransformer executes sub-queries

2016-02-28 Thread Mikhail Khludnev (JIRA)

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

Mikhail Khludnev reassigned SOLR-8208:
--

Assignee: Mikhail Khludnev

> DocTransformer executes sub-queries
> ---
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, newbie
> Attachments: SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch
>
>
> The initial idea was to return "from" side of query time join via 
> doctransformer. I suppose it isn't  query-time join specific, thus let to 
> specify any query and parameters for them, let's call them sub-query. But it 
> might be problematic to escape subquery parameters, including local ones, 
> e.g. what if subquery needs to specify own doctransformer in =\[..\] ?
> I suppose we can allow to specify subquery parameter prefix:
> {code}
> ..=id,[subquery paramPrefix=subq1. 
> fromIndex=othercore],score,..={!term f=child_id 
> v=$subq1.row.id}=3=price&..
> {code}   
> * {{paramPrefix=subq1.}} shifts parameters for subquery: {{subq1.q}} turns to 
> {{q}} for subquery, {{subq1.rows}} to {{rows}}
> * {{fromIndex=othercore}} optional param allows to run subquery on other 
> core, like it works on query time join
> * the itchiest one is to reference to document field from subquery 
> parameters, here I propose to use local param {{v}} and param deference 
> {{v=$param}} thus every document field implicitly introduces parameter for 
> subquery $\{paramPrefix\}row.$\{fieldName\}, thus above subquery is 
> q=child_id:, presumably we can drop "row." in the middle 
> (reducing to v=$subq1.id), until someone deal with {{rows}}, {{sort}} fields. 
> * \[subquery\], or \[query\], or ? 
> Caveat: it should be a way slow; it handles only search result page, not 
> entire result set. 



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

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



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

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16037/
Java: 32bit/jdk1.8.0_72 -client -XX:+UseSerialGC

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

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

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




Build Log:
[...truncated 10446 lines...]
   [junit4] Suite: org.apache.solr.cloud.UnloadDistributedZkTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.UnloadDistributedZkTest_55320CC147CEEA0D-001/init-core-data-001
   [junit4]   2> 11293 INFO  
(SUITE-UnloadDistributedZkTest-seed#[55320CC147CEEA0D]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 11312 INFO  
(TEST-UnloadDistributedZkTest.test-seed#[55320CC147CEEA0D]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 11313 INFO  (Thread-21) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 11313 INFO  (Thread-21) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 11413 INFO  

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

2016-02-28 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/900/

No tests ran.

Build Log:
[...truncated 14 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true 
fetch --tags --progress git://git.apache.org/lucene-solr.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: read error: Connection reset by peer

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1693)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1441)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:62)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:313)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to lucene(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
at hudson.remoting.Channel.call(Channel.java:781)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor407.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at com.sun.proxy.$Proxy64.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:764)
... 11 more
ERROR: null
Retrying after 10 seconds
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > git://git.apache.org/lucene-solr.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)

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

2016-02-28 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/899/

1 tests failed.
FAILED:  
org.apache.solr.handler.clustering.DistributedClusteringComponentTest.test

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:59641/_rkc/nh/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:59641/_rkc/nh/collection1
at 
__randomizedtesting.SeedInfo.seed([6807FAB45E12C596:E053C56EF0EEA86E]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:591)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:895)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:858)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:873)
at 
org.apache.solr.BaseDistributedSearchTestCase.del(BaseDistributedSearchTestCase.java:551)
at 
org.apache.solr.handler.clustering.DistributedClusteringComponentTest.test(DistributedClusteringComponentTest.java:35)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1022)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-8731) onException behavior in search components

2016-02-28 Thread Dean Gurvitz (JIRA)

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

Dean Gurvitz commented on SOLR-8731:


If there are no objections I will soon contribute my code to the master branch.

> onException behavior in search components
> -
>
> Key: SOLR-8731
> URL: https://issues.apache.org/jira/browse/SOLR-8731
> Project: Solr
>  Issue Type: New Feature
>  Components: SearchComponents - other
>Affects Versions: master
>Reporter: Dean Gurvitz
>Priority: Minor
>  Labels: features, newdev
> Fix For: master
>
> Attachments: SOLR-8731.patch
>
>
> The idea is to allow search components to execute logic in case an exception  
> was thrown while processing a query.
> A new "onException" function can be added to the SearchComponent class. Then, 
> parts of SearchHandler's handle-request functions can be surrounded in a 
> try-catch block, where onException is called within the catch section on all 
> relevant SearchComponents.



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

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



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

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/154/
Java: 32bit/jdk1.8.0_72 -client -XX:+UseG1GC

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

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([C4B729B4C383196D]:0)


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

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([C4B729B4C383196D]:0)




Build Log:
[...truncated 12521 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.HttpPartitionTest_C4B729B4C383196D-001/init-core-data-001
   [junit4]   2> 1271973 INFO  
(SUITE-HttpPartitionTest-seed#[C4B729B4C383196D]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 1271976 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1271976 INFO  (Thread-4703) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1271976 INFO  (Thread-4703) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1272076 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.ZkTestServer start zk server on port:46608
   [junit4]   2> 1272076 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1272077 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1272079 INFO  (zkCallback-1704-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@a4f252 name:ZooKeeperConnection 
Watcher:127.0.0.1:46608 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2> 1272080 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 1272080 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 1272080 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 1272083 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1272084 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1272084 INFO  (zkCallback-1705-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@1017653 name:ZooKeeperConnection 
Watcher:127.0.0.1:46608/solr got event WatchedEvent state:SyncConnected 
type:None path:null path:null type:None
   [junit4]   2> 1272085 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 1272085 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 1272085 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1
   [junit4]   2> 1272086 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1/shards
   [junit4]   2> 1272087 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection
   [junit4]   2> 1272088 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection/shards
   [junit4]   2> 1272089 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.AbstractZkTestCase put 
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 1272089 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.c.SolrZkClient makePath: /configs/conf1/solrconfig.xml
   [junit4]   2> 1272091 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 
o.a.s.c.AbstractZkTestCase put 
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/core/src/test-files/solr/collection1/conf/schema.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 1272091 INFO  
(TEST-HttpPartitionTest.test-seed#[C4B729B4C383196D]) [] 

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

2016-02-28 Thread JIRA

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

Tomás Fernández Löbbe resolved SOLR-8671.
-
Resolution: Fixed

Thanks Tom!

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



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

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



[jira] [Commented] (LUCENE-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator(); remove natural comparator in favour of Java 8 one

2016-02-28 Thread Robert Muir (JIRA)

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

Robert Muir commented on LUCENE-7053:
-

+1

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator(); remove natural 
> comparator in favour of Java 8 one
> --
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch, LUCENE-7053.patch, LUCENE-7053.patch, 
> LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. I know originally we 
> added the different comparators to be able to allow the index term dict to be 
> sorted in different order. This never proved to be useful, as many Lucene 
> queries rely on the default order. The only codec that used another byte 
> order internally was the Lucene 3 one (but it used the unicode spaghetti 
> algorithm to reorder its term enums at runtime).
> This patch also removes the BytesRef-Comparator completely and just 
> implements compareTo. So all code can rely on natural ordering.
> This patch also cleans up other usages of natural order comparators, e.g. in 
> ArrayUtil, because Java 8 natively provides a comparator.



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

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



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

2016-02-28 Thread Jack Krupansky (JIRA)

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

Jack Krupansky commented on SOLR-8110:
--

bq. "safe"... "moderate"... "legacy"

My only real nit is that it would be a shame if we couldn't say simply that 
people will be safe if they stick to Java identifier rules. That would mean $ 
and full Unicode.

My point is that it makes learning Solr more intuitive since Java is more of a 
commonly-known entity - "Solr field names are Java identifiers", rather than 
encumber people with yet another set of rules to learn.

Note that the current Solr code mostly uses 
isJavaIdentifierStart/isJavaIdentifierPart today, but disallowing $, probably 
due to parameter substitution. IOW, Unicode is there today.

See:
https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/StrParser.java
https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/SolrReturnFields.java


> Start enforcing field naming recomendations in next X.0 release?
> 
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> For a very long time now, Solr has made the following "recommendation" 
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only 
> and not start with a digit.  This is not currently strictly enforced, but 
> other field names will not have first class support from all components and 
> back compatibility is not guaranteed.  ...
> I'm opening this issue to track discussion about if/how we should start 
> enforcing this as a rule instead (instead of just a "recommendation") in our 
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with 
> lists of field and produce strange errors when the huerstic fails (example: 
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the 
> recommended conventions and then only later encountering a situation where 
> their field names are not supported by some feature and get frustrated 
> because they have to change their schema, reindex, update index/query client 
> expectations, etc...



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

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



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

2016-02-28 Thread Jack Krupansky (JIRA)

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

Jack Krupansky commented on SOLR-8110:
--

bq.  lucene expressions

I was going to say that Luceene Expressions are basically JavaScript, but... 
they are sort-of based on JS, but really more of a conceptual rather than 
literal basis. Here's Lucene's grammar rule for VARIABLE:

{code}
VARIABLE: ID ARRAY* ( [.] ID ARRAY* )*;
fragment ARRAY: [[] ( STRING | INTEGER ) [\]];
fragment ID: [_$a-zA-Z] [_$a-zA-Z0-9]*;
fragment STRING
: ['] ( '\\\'' | '' | ~[\\'] )*? [']
| ["] ( '\\"' | '' | ~[\\"] )*? ["]
;
{code}

See:
https://github.com/apache/lucene-solr/blob/master/lucene/expressions/src/java/org/apache/lucene/expressions/js/Javascript.g4

No Unicode support, no random special characters, just $ and _, but apparently 
dot as well.

An ID is:

{code}
ID: [_$a-zA-Z] [_$a-zA-Z0-9]*
{code}

And any number of IDs can be written with dots between them to represent a 
single VARIABLE token.

JavaScript identifiers are defined in the ECMAScript spec:
https://tc39.github.io/ecma262/#prod-IdentifierName

Letters in Java/ECMAScript are Unicode as defined by the Unicode property 
“ID_Start” and "ID_Continue". Java/ECMAScript supports $ and _ in addition to 
letters.

Identifier start and continue character types are defined by the Unicode UAX#31 
 Identifier spec:
http://unicode.org/reports/tr31/


> Start enforcing field naming recomendations in next X.0 release?
> 
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> For a very long time now, Solr has made the following "recommendation" 
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only 
> and not start with a digit.  This is not currently strictly enforced, but 
> other field names will not have first class support from all components and 
> back compatibility is not guaranteed.  ...
> I'm opening this issue to track discussion about if/how we should start 
> enforcing this as a rule instead (instead of just a "recommendation") in our 
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with 
> lists of field and produce strange errors when the huerstic fails (example: 
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the 
> recommended conventions and then only later encountering a situation where 
> their field names are not supported by some feature and get frustrated 
> because they have to change their schema, reindex, update index/query client 
> expectations, etc...



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

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



[jira] [Commented] (LUCENE-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator(); remove natural comparator in favour of Java 8 one

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-7053:
---

All tests pass.

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator(); remove natural 
> comparator in favour of Java 8 one
> --
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch, LUCENE-7053.patch, LUCENE-7053.patch, 
> LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. I know originally we 
> added the different comparators to be able to allow the index term dict to be 
> sorted in different order. This never proved to be useful, as many Lucene 
> queries rely on the default order. The only codec that used another byte 
> order internally was the Lucene 3 one (but it used the unicode spaghetti 
> algorithm to reorder its term enums at runtime).
> This patch also removes the BytesRef-Comparator completely and just 
> implements compareTo. So all code can rely on natural ordering.
> This patch also cleans up other usages of natural order comparators, e.g. in 
> ArrayUtil, because Java 8 natively provides a comparator.



--
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-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator(); remove natural comparator in favour of Java 8 one

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler updated LUCENE-7053:
--
Description: 
Followup from LUCENE-7052: This removes the legacy, deprecated 
getUTF8SortedAsUTF16Comparator() in the BytesRef class. I know originally we 
added the different comparators to be able to allow the index term dict to be 
sorted in different order. This never proved to be useful, as many Lucene 
queries rely on the default order. The only codec that used another byte order 
internally was the Lucene 3 one (but it used the unicode spaghetti algorithm to 
reorder its term enums at runtime).

This patch also removes the BytesRef-Comparator completely and just implements 
compareTo. So all code can rely on natural ordering.

This patch also cleans up other usages of natural order comparators, e.g. in 
ArrayUtil, because Java 8 natively provides a comparator.

  was:
Followup from LUCENE-7052: This removes the legacy, deprecated 
getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over user 
was TSTLookup. Moves the code there as private impl detail.

This also converts the comparators to lambdas for better readability.

Summary: Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator(); 
remove natural comparator in favour of Java 8 one  (was: Remove deprecated 
BytesRef#getUTF8SortedAsUTF16Comparator())

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator(); remove natural 
> comparator in favour of Java 8 one
> --
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch, LUCENE-7053.patch, LUCENE-7053.patch, 
> LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. I know originally we 
> added the different comparators to be able to allow the index term dict to be 
> sorted in different order. This never proved to be useful, as many Lucene 
> queries rely on the default order. The only codec that used another byte 
> order internally was the Lucene 3 one (but it used the unicode spaghetti 
> algorithm to reorder its term enums at runtime).
> This patch also removes the BytesRef-Comparator completely and just 
> implements compareTo. So all code can rely on natural ordering.
> This patch also cleans up other usages of natural order comparators, e.g. in 
> ArrayUtil, because Java 8 natively provides a comparator.



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

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



[jira] [Comment Edited] (LUCENE-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler edited comment on LUCENE-7053 at 2/28/16 4:02 PM:


Here is the comparator cleanup. I removed usage of the BytesRef comparator 
completely (where possible). Otherwise I used {{Comparator.naturalOrder()}}.

I also removed the {{ArrayUtil.naturalComparator()}} method, because it is 
obsolete with Java 8.


was (Author: thetaphi):
Here is the comparator cleanup. I removed usage of the BytesRef comparator 
completely (where possible). Otherwise I used {{Comparator.naturalOrder()}}.

I also removed the {ArrayUtil.naturalComparator()}} method, because it is 
obsolete with Java 8.

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch, LUCENE-7053.patch, LUCENE-7053.patch, 
> LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



--
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-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler updated LUCENE-7053:
--
Attachment: LUCENE-7053.patch

Here is the comparator cleanup. I removed usage of the BytesRef comparator 
completely (where possible). Otherwise I used {{Comparator.naturalOrder()}}.

I also removed the {ArrayUtil.naturalComparator()}} method, because it is 
obsolete with Java 8.

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch, LUCENE-7053.patch, LUCENE-7053.patch, 
> LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



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

2016-02-28 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/896/

2 tests failed.
FAILED:  
org.apache.solr.handler.dataimport.TestContentStreamDataSource.testSimple

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:45096/solr/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:45096/solr/collection1
at 
__randomizedtesting.SeedInfo.seed([97455B17E47D0D8D:AFF67FE9C38ED95C]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:591)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.handler.dataimport.TestContentStreamDataSource.testSimple(TestContentStreamDataSource.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Robert Muir (JIRA)

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

Robert Muir commented on LUCENE-7053:
-

Yes, please, and remove BytesRef.COMPARATOR which just duplicates that: 
naturalOrder() already returns a singleton.

Also in cases like TreeSet creation in the join tests, we should just make 
{{new TreeSet<>()}} and not pass any comparator in at all.

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch, LUCENE-7053.patch, LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



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

2016-02-28 Thread Yonik Seeley (JIRA)

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

Yonik Seeley updated SOLR-8741:
---
Component/s: Facet Module

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



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

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



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

2016-02-28 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/894/

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

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

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

[jira] [Comment Edited] (LUCENE-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler edited comment on LUCENE-7053 at 2/28/16 12:47 PM:
-

As we implemented {{compareTo}} we could remove the comparator completely. One 
could use {{Comparator.naturalOrder()}}(see 
[[https://docs.oracle.com/javase/8/docs/api/java/util/Comparator.html#naturalOrder--]])
 instead (naturalOrder is defined to use {{compareTo}}. At places like 
Collections.sort() we could remove the comparator argument completely.

Any comments on this?


was (Author: thetaphi):
As we implemented {{compareTo}} we could remove the comparator completely. One 
could use {{Collections.naturalOrder()}} instead (naturalOrder is defined to 
use {{compareTo}}. At places like Collections.sort() we could remove the 
comparator argument completely.

Any comments on this?

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch, LUCENE-7053.patch, LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



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

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



[jira] [Comment Edited] (LUCENE-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler edited comment on LUCENE-7053 at 2/28/16 12:48 PM:
-

As we implemented {{compareTo}} we could remove the comparator completely. One 
could use {{Comparator.naturalOrder()}} (see 
[https://docs.oracle.com/javase/8/docs/api/java/util/Comparator.html#naturalOrder--])
 instead (naturalOrder is defined to use {{compareTo}}. At places like 
Collections.sort() we could remove the comparator argument completely.

Any comments on this?


was (Author: thetaphi):
As we implemented {{compareTo}} we could remove the comparator completely. One 
could use {{Comparator.naturalOrder()}}(see 
[[https://docs.oracle.com/javase/8/docs/api/java/util/Comparator.html#naturalOrder--]])
 instead (naturalOrder is defined to use {{compareTo}}. At places like 
Collections.sort() we could remove the comparator argument completely.

Any comments on this?

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch, LUCENE-7053.patch, LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



--
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-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-7053:
---

As we implemented {{compareTo}} we could remove the comparator completely. One 
could use {{Collections.naturalOrder()}} instead (naturalOrder is defined to 
use {{compareTo}}. At places like Collections.sort() we could remove the 
comparator argument completely.

Any comments on this?

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch, LUCENE-7053.patch, LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



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

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



[jira] [Comment Edited] (LUCENE-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler edited comment on LUCENE-7053 at 2/28/16 12:27 PM:
-

New patch:
- I removed some usage of comparator and replaced by {{compareTo}} at many 
places.
- Moved the code of the comparator to {{compareTo}}.
- The comparator isstelf is now a static final constant {{BytesRef.COMPARATOR}} 
(the name was horrible). It is documented to just order by bytes. In fact its 
just a method reference to the {{compareTo}} method!
- I also removed the chicken-egg statement in FuzzyQuery.


was (Author: thetaphi):
New patch:
- I removed useless usage of comparator at some places and replace by compareTo
- Moved the code of the comparator to compareTo.
- The comparator isstelf is now a static constant BytesRef.COMPARATOR (the name 
was horrible). It is documented to just order by bytes. In fact its just a 
method reference to the compareTo method!
- I also removed the chicken-egg statement in FuzzyQuery

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch, LUCENE-7053.patch, LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



--
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-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler updated LUCENE-7053:
--
Attachment: LUCENE-7053.patch

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch, LUCENE-7053.patch, LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



--
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-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler updated LUCENE-7053:
--
Attachment: (was: LUCENE-7053.patch)

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch, LUCENE-7053.patch, LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



--
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-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler updated LUCENE-7053:
--
Attachment: LUCENE-7053.patch

New patch:
- I removed useless usage of comparator at some places and replace by compareTo
- Moved the code of the comparator to compareTo.
- The comparator isstelf is now a static constant BytesRef.COMPARATOR (the name 
was horrible). It is documented to just order by bytes. In fact its just a 
method reference to the compareTo method!
- I also removed the chicken-egg statement in FuzzyQuery

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch, LUCENE-7053.patch, LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



--
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-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler updated LUCENE-7053:
--
Attachment: LUCENE-7053.patch

New patch with Mike's suggestions. I added a comparator static final constant 
to TestUtil with a warning that it is not as effective as it could be 
([~dawid.weiss] comment on LUCENE-7052).

I did not yet look into further cleaning up and removing comparator usage.

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch, LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



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

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/3117/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

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

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

[jira] [Commented] (LUCENE-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-7053:
---

bq. We can take this further, e.g. I grep'd for places calling 
BytesRef.getUTF8SortedAsUnicodeComparator and it turns up silliness in 
BlockTermsReader that should just be invoking BytesRef.compareTo directly 
instead, I think?

Yeah. As said, we may not remove the comparator completely, but we should only 
use it at places where we can't use {{Comparable}} interface that 
BytesRef implements.

bq. You can also fix TestUnicodeUtil's custom String -> int[] code points logic 
maybe?

Will check this, too. I am currently investigating it Java 8 already has some 
Comparator interface somewhere ready-to use. But does not look like that.

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



--
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-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Michael McCandless (JIRA)

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

Michael McCandless commented on LUCENE-7053:


+1 to the patch.

You can also fix {{TestUnicodeUtil}}'s custom String -> int[] code points logic 
maybe?

bq. There is a bit code duplication in both tests (sorting Strings in code 
point order), should we maybe move the new comparator to TestUtil?

+1

We can take this further, e.g. I grep'd for places calling 
{{BytesRef.getUTF8SortedAsUnicodeComparator}} and it turns up silliness in 
{{BlockTermsReader}} that should just be invoking {{BytesRef.compareTo}} 
directly instead, I think?

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



--
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-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-7053:
---

There is a bit code duplication in both tests (sorting Strings in code point 
order), should we maybe move the new comparator to TestUtil?

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



--
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-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler updated LUCENE-7053:
--
Attachment: LUCENE-7053.patch

Patch (copy from LUCENE-7052).

> Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()
> ---
>
> Key: LUCENE-7053
> URL: https://issues.apache.org/jira/browse/LUCENE-7053
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.0
>
> Attachments: LUCENE-7053.patch
>
>
> Followup from LUCENE-7052: This removes the legacy, deprecated 
> getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over 
> user was TSTLookup. Moves the code there as private impl detail.
> This also converts the comparators to lambdas for better readability.



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

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



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

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-7052:
---

New issue: LUCENE-7053

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



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

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



[jira] [Created] (LUCENE-7053) Remove deprecated BytesRef#getUTF8SortedAsUTF16Comparator()

2016-02-28 Thread Uwe Schindler (JIRA)
Uwe Schindler created LUCENE-7053:
-

 Summary: Remove deprecated 
BytesRef#getUTF8SortedAsUTF16Comparator()
 Key: LUCENE-7053
 URL: https://issues.apache.org/jira/browse/LUCENE-7053
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/other
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: master, 6.0


Followup from LUCENE-7052: This removes the legacy, deprecated 
getUTF8SortedAsUTF16Comparator() in the BytesRef class. The only left over user 
was TSTLookup. Moves the code there as private impl detail.

This also converts the comparators to lambdas for better readability.



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

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



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

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-7052:
---

I wil open now other issue with the attached patch. As the [~steve_rowe] 
suggestion is implemented there, we can leave THIS issue closed.

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



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

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



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

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler updated LUCENE-7052:
--
Attachment: LUCENE-7052-cleanup1.patch

Hi Mike, here is a patch, moving the UTF-16 comparator away and clean up code.

I also changed the TreeSet comparator to a lambda using 
{{CharSequence#codePoints()}} because I hit the same in another test :-)

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



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

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



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

2016-02-28 Thread Michael McCandless (JIRA)

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

Michael McCandless commented on LUCENE-7052:


bq. Mike, should I open a new issue for the comparator cleanups. I have the 
patch almost ready?

Yes please!!

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



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

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



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

2016-02-28 Thread Michael McCandless (JIRA)

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

Michael McCandless commented on LUCENE-7052:


{{TestUnicodeUtil.testUTF8toUTF32}} (and I'm sure other places) can also 
cutover to {{CharSequence.codePoints}}.

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



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

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



[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk-9-ea+107) - Build # 16034 - Still Failing!

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16034/
Java: 64bit/jdk-9-ea+107 -XX:-UseCompressedOops -XX:+UseG1GC

56 tests failed.
FAILED:  
org.apache.lucene.codecs.lucene54.TestLucene54DocValuesFormat.testSortedSetVariableLengthFewUniqueSetsVsStoredFields

Error Message:
Unable to unmap the mapped buffer: 
MMapIndexInput(path="/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/J0/temp/lucene.codecs.lucene54.TestLucene54DocValuesFormat_EE9D51BB35C14382-001/dvduel-001/_1_Lucene54_0.dvm")

Stack Trace:
java.io.IOException: Unable to unmap the mapped buffer: 
MMapIndexInput(path="/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/J0/temp/lucene.codecs.lucene54.TestLucene54DocValuesFormat_EE9D51BB35C14382-001/dvduel-001/_1_Lucene54_0.dvm")
at 
__randomizedtesting.SeedInfo.seed([EE9D51BB35C14382:751E85E3EC89B331]:0)
at 
org.apache.lucene.store.MMapDirectory.lambda$initUnmapHack$1(MMapDirectory.java:384)
at 
org.apache.lucene.store.ByteBufferIndexInput.freeBuffer(ByteBufferIndexInput.java:376)
at 
org.apache.lucene.store.ByteBufferIndexInput.close(ByteBufferIndexInput.java:355)
at 
org.apache.lucene.util.LuceneTestCase.slowFileExists(LuceneTestCase.java:2680)
at 
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:732)
at 
org.apache.lucene.store.FilterDirectory.openInput(FilterDirectory.java:94)
at 
org.apache.lucene.index.IndexWriter.slowFileExists(IndexWriter.java:4814)
at org.apache.lucene.index.IndexWriter.filesExist(IndexWriter.java:4351)
at 
org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4422)
at 
org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2876)
at 
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2989)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2956)
at 
org.apache.lucene.index.RandomIndexWriter.commit(RandomIndexWriter.java:288)
at 
org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestSortedSetVsStoredFields(BaseDocValuesFormatTestCase.java:1983)
at 
org.apache.lucene.index.BaseDocValuesFormatTestCase.testSortedSetVariableLengthFewUniqueSetsVsStoredFields(BaseDocValuesFormatTestCase.java:2176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

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

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-7052:
---

Mike, should I open a new issue for the comparator cleanups. I have the patch 
almost ready?

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



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

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



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

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-7052:
---

+1 to [~steve_rowe] change. We are on Java 8, so use Java 8 methods.

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



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

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



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

2016-02-28 Thread Michael McCandless (JIRA)

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

Michael McCandless commented on LUCENE-7052:


bq. Mike, why did you add an implementation of codePoints() instead of using 
the CharSequence version (returning IntStream) + toArray()? 

Oh, because I didn't even know about {{CharSequence.codePoints}}!

+1 to your patch, thanks.

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

It's definitely inefficient (converting to a sortable key on every comparison), 
but it keeps the code simple, which I think is usually the right tradeoff for a 
test case?

bq. As this is now all gone, I'd suggest to also remove the utf8AsUtf16 
comparator. Mabye remove the comparators at all and just implement 
BytesRef.compareTo() and use that one for sorting?

+1, that sounds awesome!

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



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

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



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

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-7052:
---

Oh this was already committed. Maybe open another issue to remove the obsolete 
comparator and convert to lambda.

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



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

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



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

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler edited comment on LUCENE-7052 at 2/28/16 10:34 AM:
-

Hi Mike,
I know originally we added the different comparators to be able to allow the 
index term dict to be sorted in different order. This never prooved to be 
useful, as many Lucene queries rely on the default order. The only codec that 
used another byte order internally was the Lucene 3 one (but it used the 
unicode spaghetti algorithm to reorder its term enums at runtime). As this is 
now all gone, I'd suggest to also remove the utf8AsUtf16 comparator. Mabye 
remove the comparators at all and just implement BytesRef.compareTo() and use 
that one for sorting?

I checked the code: utf8SortedAsUTF16SortOrder is only used in TSTLookup 
nowhere else anymore (except some test that check alternative sorts - those can 
be removed).

As a first step I changed the BytesRef code to no longer use inner classes and 
instead use a lambda to define the comparators. But I'd suggest to remove at 
least the UTF-16 one completely and move it as private impl detail to TSTLookup 
(as only used there).

_FYI: The lambda has no speed impact because it is called only once and 
internally compiles to a class file that implements Comparator. It just looks 
nicer than the horrible comparator classes_


was (Author: thetaphi):
Hi Mike,
I know originally we added the different comparators to be able to allow the 
index term dict to be sorted in different order. This never prooved to be 
useful, as many Lucene queries rely on the default order. The only codec that 
used another byte order internally was the Lucene 3 one (but it used the 
unicode spaghetti algorithm to reorder its term enums at runtime). As this is 
now all gone, I'd suggest to also remove the utf8AsUtf16 comparator. Mabye 
remove the comparators at all and just implement BytesRef.compareTo() and use 
that one for sorting?

I checked the code: utf8SortedAsUTF16SortOrder is only used in TSTLookup 
nowhere else anymore (except some test that check alternative sorts - those can 
be removed).

As a first step I changed the BytesRef code to no longer use inner classes and 
instead use a lambda to define the comparators. But I'd suggest to remove at 
least the UTF-16 one completely and move it as private impl detail and move it 
hidden TSTLookup (as only used there).

_FYI: The lambda has no speed impact because it is called only once and 
internally compiles to a class file that implements Comparator. It just looks 
nicer than the horrible comparator classes_

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



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

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



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

2016-02-28 Thread Uwe Schindler (JIRA)

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

Uwe Schindler updated LUCENE-7052:
--
Attachment: LUCENE-7052-cleanup1.patch

Hi Mike,
I know originally we added the different comparators to be able to allow the 
index term dict to be sorted in different order. This never prooved to be 
useful, as many Lucene queries rely on the default order. The only codec that 
used another byte order internally was the Lucene 3 one (but it used the 
unicode spaghetti algorithm to reorder its term enums at runtime). As this is 
now all gone, I'd suggest to also remove the utf8AsUtf16 comparator. Mabye 
remove the comparators at all and just implement BytesRef.compareTo() and use 
that one for sorting?

I checked the code: utf8SortedAsUTF16SortOrder is only used in TSTLookup 
nowhere else anymore (except some test that check alternative sorts - those can 
be removed).

As a first step I changed the BytesRef code to no longer use inner classes and 
instead use a lambda to define the comparators. But I'd suggest to remove at 
least the UTF-16 one completely and move it as private impl detail and move it 
hidden TSTLookup (as only used there).

_FYI: The lambda has no speed impact because it is called only once and 
internally compiles to a class file that implements Comparator. It just looks 
nicer than the horrible comparator classes_

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



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

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



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

2016-02-28 Thread Marius Grama (JIRA)

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

Marius Grama commented on SOLR-8721:


[~arafalov] i've included the solr-impl-version and lucene-impl-version because 
I've seen them provided in the Solr admin dashboard.

I've removed them now and the debug info looks like this : 

{code}
"debug": {
"solr-spec-version": "5.5.0",
"lucene-spec-version": "5.5.0",
...
}
{code}


bq. On the other hand, is there a value is sending what lucene version the 
solrconfig.xml file pegs the core at?
Could you please describe in more detail what you mean by this question?

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



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

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



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

2016-02-28 Thread Marius Grama (JIRA)

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

Marius Grama edited comment on SOLR-8721 at 2/28/16 10:10 AM:
--

[~arafalov] i've included the solr-impl-version and lucene-impl-version because 
I've seen them provided in the Solr admin dashboard and I thought they could be 
relevant.

I've removed them now and the debug info looks like this : 

{code}
"debug": {
"solr-spec-version": "5.5.0",
"lucene-spec-version": "5.5.0",
...
}
{code}


bq. On the other hand, is there a value is sending what lucene version the 
solrconfig.xml file pegs the core at?
Could you please describe in more detail what you mean by this question?


was (Author: mariusneo):
[~arafalov] i've included the solr-impl-version and lucene-impl-version because 
I've seen them provided in the Solr admin dashboard.

I've removed them now and the debug info looks like this : 

{code}
"debug": {
"solr-spec-version": "5.5.0",
"lucene-spec-version": "5.5.0",
...
}
{code}


bq. On the other hand, is there a value is sending what lucene version the 
solrconfig.xml file pegs the core at?
Could you please describe in more detail what you mean by this question?

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



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

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



[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk-9-ea+107) - Build # 16033 - Still Failing!

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16033/
Java: 64bit/jdk-9-ea+107 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.lucene.util.automaton.TestDeterminism.testAgainstSimple

Error Message:
7

Stack Trace:
java.lang.ArrayIndexOutOfBoundsException: 7
at 
__randomizedtesting.SeedInfo.seed([66057EEB16E4C6E9:5C36060EFADD97EE]:0)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:524)
at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:510)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomSingleAutomaton(AutomatonTestUtil.java:262)
at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomAutomaton(AutomatonTestUtil.java:276)
at 
org.apache.lucene.util.automaton.TestDeterminism.testAgainstSimple(TestDeterminism.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:804)




Build Log:
[...truncated 1001 

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

2016-02-28 Thread Policeman Jenkins Server
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16032/
Java: 32bit/jdk1.8.0_72 -server -XX:+UseParallelGC

39 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([8B835E561A2C2F48]:0)


FAILED:  org.apache.solr.TestDistributedMissingSort.test

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:36198//collection1
at 
__randomizedtesting.SeedInfo.seed([8B835E561A2C2F48:3D7618CB4D042B0]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:591)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:895)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:858)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:873)
at 
org.apache.solr.BaseDistributedSearchTestCase.del(BaseDistributedSearchTestCase.java:551)
at 
org.apache.solr.TestDistributedMissingSort.index(TestDistributedMissingSort.java:48)
at 
org.apache.solr.TestDistributedMissingSort.test(TestDistributedMissingSort.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1022)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 946 - Still Failing

2016-02-28 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/946/

2 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexWriterThreadsToSegments.testSegmentCountOnFlushRandom

Error Message:
Captured an uncaught exception in thread: Thread[id=12751, name=Thread-11913, 
state=RUNNABLE, group=TGRP-TestIndexWriterThreadsToSegments]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=12751, name=Thread-11913, state=RUNNABLE, 
group=TGRP-TestIndexWriterThreadsToSegments]
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
at __randomizedtesting.SeedInfo.seed([B21E427757BEFDEC]:0)
at java.util.HashMap.newNode(HashMap.java:1734)
at java.util.HashMap.putVal(HashMap.java:641)
at java.util.HashMap.put(HashMap.java:611)
at java.util.HashSet.add(HashSet.java:219)
at 
org.apache.lucene.index.IndexWriter$ReaderPool.noDups(IndexWriter.java:689)
at 
org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:678)
at 
org.apache.lucene.index.IndexWriter.numDeletedDocs(IndexWriter.java:704)
at org.apache.lucene.index.IndexWriter.segString(IndexWriter.java:4316)
at org.apache.lucene.index.IndexWriter.segString(IndexWriter.java:4306)
at org.apache.lucene.index.IndexWriter.segString(IndexWriter.java:4293)
at 
org.apache.lucene.index.ConcurrentMergeScheduler.merge(ConcurrentMergeScheduler.java:481)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1946)
at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:464)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenFromWriter(StandardDirectoryReader.java:291)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:266)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:256)
at 
org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:140)
at 
org.apache.lucene.index.TestIndexWriterThreadsToSegments$CheckSegmentCount.run(TestIndexWriterThreadsToSegments.java:130)
at java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:220)
at java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:362)
at 
org.apache.lucene.index.TestIndexWriterThreadsToSegments$2.run(TestIndexWriterThreadsToSegments.java:215)


FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestIndexWriterThreadsToSegments

Error Message:
The test or suite printed 18864 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 18864 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([B21E427757BEFDEC]:0)
at 
org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:211)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 1465 lines...]
   [junit4] Suite: org.apache.lucene.index.TestIndexWriterThreadsToSegments
   [junit4]   2> Feb 28, 2016 9:08:46 AM 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> WARNING: Uncaught exception in thread: 
Thread[Thread-11913,5,TGRP-TestIndexWriterThreadsToSegments]
   [junit4]   2> java.lang.OutOfMemoryError: GC overhead limit exceeded
   [junit4]   2>at 
__randomizedtesting.SeedInfo.seed([B21E427757BEFDEC]:0)
   [junit4]   2>at java.util.HashMap.newNode(HashMap.java:1734)
   [junit4]   2>at java.util.HashMap.putVal(HashMap.java:641)
   [junit4]   2>at java.util.HashMap.put(HashMap.java:611)
   [junit4]   2>at java.util.HashSet.add(HashSet.java:219)
   [junit4]   2>