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

[Policeman Jenkins Server]

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

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 1) Thread[id=10927, 
name=apacheds, state=WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] 
at java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)2) Thread[id=10930, 
name=ou=system.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)3) Thread[id=10931, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)4) Thread[id=10929, 
name=groupCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)5) Thread[id=10928, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b78) - Build # 14119 - Failure!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([42D0EE51FF0AFE50:E59456F592B1EDE9]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319)
at 
org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplicationAfterPeerSync(CdcrReplicationHandlerTest.java:158)
at 
org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:53)
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:504)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementA

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

[Apache Jenkins Server]

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

2 tests failed.
REGRESSION:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test

Error Message:
shard1 is not consistent.  Got 1361 from 
http://127.0.0.1:39719/collection1lastClient and got 706 from 
http://127.0.0.1:37092/collection1

Stack Trace:
java.lang.AssertionError: shard1 is not consistent.  Got 1361 from 
http://127.0.0.1:39719/collection1lastClient and got 706 from 
http://127.0.0.1:37092/collection1
at 
__randomizedtesting.SeedInfo.seed([860E0799691B06A6:E5A3843C7E76B5E]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1246)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1225)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:165)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5229/
Java: 32bit/jdk1.8.0_60 -client -XX:+UseParallelGC

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

Error Message:
[index.20150904163632831, index.20150904163646363, index.properties, 
replication.properties] expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: [index.20150904163632831, index.20150904163646363, 
index.properties, replication.properties] expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([B44FC84AE882CDD4:6FE4C88CEDAAA467]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:818)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:785)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomize

[jira] [Commented] (SOLR-7746) Ping requests stopped working with distrib=true in Solr 5.2.1

[Michael Sun (JIRA)]

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

Michael Sun commented on SOLR-7746:
---

Thanks [~gchanan] for pointing it out. I updated the patch and uploaded it.

> Ping requests stopped working with distrib=true in Solr 5.2.1
> -
>
> Key: SOLR-7746
> URL: https://issues.apache.org/jira/browse/SOLR-7746
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Alexey Serba
>Assignee: Gregory Chanan
> Attachments: SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch, 
> SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch
>
>
> {noformat:title="steps to reproduce"}
> # start 1 node SolrCloud cluster
> sh> ./bin/solr -c -p 
> # create a test collection (we won’t use it, but I just want to it to load 
> solr configs to Zk)
> ./bin/solr create_collection -c test -d sample_techproducts_configs -p 
> # create another test collection with 2 shards
> curl 
> 'http://localhost:/solr/admin/collections?action=CREATE&name=test2&numShards=2&replicationFactor=1&maxShardsPerNode=2&collection.configName=test'
> # try distrib ping request
> curl 
> 'http://localhost:/solr/test2/admin/ping?wt=json&distrib=true&indent=true'
> ...
>   "error":{
> "msg":"Ping query caused exception: Error from server at 
> http://192.168.59.3:/solr/test2_shard2_replica1: Cannot execute the 
> PingRequestHandler recursively"
> ...
> {noformat}
> {noformat:title="Exception"}
> 2116962 [qtp599601600-13] ERROR org.apache.solr.core.SolrCore  [test2 shard2 
> core_node1 test2_shard2_replica1] – org.apache.solr.common.SolrException: 
> Cannot execute the PingRequestHandler recursively
>   at 
> org.apache.solr.handler.PingRequestHandler.handlePing(PingRequestHandler.java:246)
>   at 
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:211)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> {noformat}



--
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-7746) Ping requests stopped working with distrib=true in Solr 5.2.1

[Michael Sun (JIRA)]

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

Michael Sun updated SOLR-7746:
--
Attachment: SOLR-7746.patch

> Ping requests stopped working with distrib=true in Solr 5.2.1
> -
>
> Key: SOLR-7746
> URL: https://issues.apache.org/jira/browse/SOLR-7746
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Alexey Serba
>Assignee: Gregory Chanan
> Attachments: SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch, 
> SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch
>
>
> {noformat:title="steps to reproduce"}
> # start 1 node SolrCloud cluster
> sh> ./bin/solr -c -p 
> # create a test collection (we won’t use it, but I just want to it to load 
> solr configs to Zk)
> ./bin/solr create_collection -c test -d sample_techproducts_configs -p 
> # create another test collection with 2 shards
> curl 
> 'http://localhost:/solr/admin/collections?action=CREATE&name=test2&numShards=2&replicationFactor=1&maxShardsPerNode=2&collection.configName=test'
> # try distrib ping request
> curl 
> 'http://localhost:/solr/test2/admin/ping?wt=json&distrib=true&indent=true'
> ...
>   "error":{
> "msg":"Ping query caused exception: Error from server at 
> http://192.168.59.3:/solr/test2_shard2_replica1: Cannot execute the 
> PingRequestHandler recursively"
> ...
> {noformat}
> {noformat:title="Exception"}
> 2116962 [qtp599601600-13] ERROR org.apache.solr.core.SolrCore  [test2 shard2 
> core_node1 test2_shard2_replica1] – org.apache.solr.common.SolrException: 
> Cannot execute the PingRequestHandler recursively
>   at 
> org.apache.solr.handler.PingRequestHandler.handlePing(PingRequestHandler.java:246)
>   at 
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:211)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> {noformat}



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

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

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

[Policeman Jenkins Server]

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

1 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([B2CC6C6802FB68B3:45BF8230C413C755]: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:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 10187 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J2/temp/solr.handler.TestRepl

[jira] [Updated] (SOLR-6168) enhance collapse QParser so that "group head" documents can be selected by more complex sort options

[Hoss Man (JIRA)]

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

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


Now, in the context of this being a feature request, some comments based on my 
notes from the last few days...



I have some concerns about hte appraoch taken in Umesh's patch (NOTE: patch 
appears to have been generated in reverse)...

* Instead of introducing a new option for letting users pick arbitrary sort 
criteria to select the group heads, it only allows using the top level 'sort' 
param for this (if the min/max local params are not specified)
** This means that it breaks backcompat for existing users who use the collapse 
QParsers current default behavior of "pick groupHead having highest score" if 
they are alreayd using some other sort.
*** This is evident in some existing tests that the patch changes
** This also means that it doesn't give users any (new) method of picking the 
group heads using a complex sort different from the sort that is applied after 
the collapse -- so if you want the collapsed docs sorted by X, your only 
options for picking the groupHeads is to use X, or to use the min/max of a 
single field like today
* Rather then re-using any of the existing document sort param parsing logic, 
or internal Sorting code from Solr/Lucene, Umesh's patch adds it's own 
(limited) parsing of the 'sort' param, to build up a data structure wrapped 
arround the existing simplistic min/max value groupHead selector logic
** this means a lot of new hairy code
** this also means Sorts with non-trivial clauses won't work at all, examples:
*** function clauses
*** fields that use sortMissingFirst or sortMissingLast
*** custom FieldType implementations that define their own sort logic.



After reviewing Umesh's patch, and thinking about it a bit, I spent some time 
the past few days working up a straw man for an alternate approach that adds a 
new sort "localparam" and leverages the existing Lucene/Solr Sorting code to 
parse it and process it.  The idea being you could do something like this to 
select the group head docs based on a complex sort which is independent of the 
final sort used for the collapsed docs...

{noformat}
{!collapse field=manu_id_s sort='price asc, popularity desc%'}
{noformat}

...but you can still trivially use the same sort for both (like in Umesh's 
patch) by refrencing the top level sort as a variable...

{noformat}
{!collapse field=manu_id_s sort=$sort}
{noformat}


The attached patch has the bare bones beginings of this approach, along with a 
simple test (addapted from Umesh's original patch).   It only supports 
collapsing on String fields at the moment, but the sort you choose to collapse 
on can be (almost) anything -- So both of the above examples will/should work 
as expected using the "techproducts" example if you apply this patch to trunk...

* 
http://localhost:8983/solr/techproducts/select?fl=id,manu_id_s,price,weight,popularity&q=*:*&sort=weight+asc&fq=%7b!collapse%20field=manu_id_s%20sort=%27price%20asc,%20popularity%20desc%27%7d
* 
http://localhost:8983/solr/techproducts/select?fl=id,manu_id_s,weight&q=*:*&sort=weight+asc&fq=%7b!collapse%20field=manu_id_s%20sort=$sort%7d


>From what i can tell, this general approach should still work fairly 
>consisntly when collapsing on non-string field types, it's just going to 
>require some (seemingly) straight forward new code & refactoring. (and of 
>course lots of tests).  There's also several nocommits in the patch related to 
>some refactoring that i think will be neccessary to address some edge cases 
>issues (notably arround using "cscore()" inside of an arbitrary sort 
>expression), but i'm pretty confident that the general appraoch is sound.

I plan to continue working on this approach over the next few weeks, focusing 
first on more test cases -- but I wanted to get this initial patch out there 
for discussion in case anyone had strong opinions about it, or sees any 
fundemental flaws with the design.





> enhance collapse QParser so that "group head" documents can be selected by 
> more complex sort options
> 
>
> Key: SOLR-6168
> URL: https://issues.apache.org/jira/browse/SOLR-6168
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.7.1, 4.8.1
>Reporter: Umesh Prasad
>Assignee: Joel Bernstein
> Attachments: CollapsingQParserPlugin-6168.patch.1-1stcut, 
> SOLR-6168-group-head-inconsistent-with-sort.patch, SOLR-6168.patch
>
>
> The fundemental goal of this issue is add additional support to the 
> CollapseQParser so that as an alternative to the existing min/max localparam 
> options, more robust sort syntax can be used to sort on multiple criteria 
> when selecting the "group head" docu

[jira] [Updated] (SOLR-6168) ehance collapse QParser so that "group head" documents can be selected by more complex sort options

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-6168:
---
Description: 




The fundemental goal of this issue is add additional support to the 
CollapseQParser so that as an alternative to the existing min/max localparam 
options, more robust sort syntax can be used to sort on multiple criteria when 
selecting the "group head" documents used to represent each collapsed group.

Since support for arbitrary, multi-clause, sorting is almost certainly going to 
require more RAM then the existing min/max functionaly, this new functionality 
should be in addition to the existing min/max localparam implementation, not a 
replacement of it.

(NOTE: early comments made in this jira may be confusing in historical context 
due to the way this issue was originally filed as a bug report)

  was:
CollapsingQParser Plugin ranks documents incorrectly when more than 2 sort 
fields are used.
   I have attached a test case, which demonstrates the broken behavior when 3 
sort fields are used.

The failing test case patch is against Lucene/Solr 4.8.1 revision  number 
1603061

PS : SOLR-5408 fixed the issue with sorting only for two sort fields, by 
allowing one to specify max/min=. However that requires 2nd sort 
field to be a numeric field. It will not work with string field or function 
query sort.




 Issue Type: Improvement  (was: Bug)
Summary: ehance collapse QParser so that "group head" documents can be 
selected by more complex sort options  (was: CollapsingQParserPlugin ranks 
incorrectly when 3 or more sort params are used)


I was recently asked about this issue, and when i initially started digging 
into it got more and more confused.

It seems that fundementally, what happened here is that Umesh initially filled 
a _bug_ regarding the way the collapse QParser selects the "group head" -- but 
this bug report was based on a missunderstanding about what default behavior of 
CollapseQParser is when dealing with a sort param (as compared to the older 
GroupingCOmponent).

There was some key discussiong about this issue on the solr-user mailing list, 
which did *not* result in updating the summary/description of this issue, 
followed by Umesh attaching a patch ettempting to implement some changes in 
behavior.

I have some thoughts on Umesh's approach, and my own suggestions, but before I 
get into that i want to make sure the situation is accurately represented in 
this Jira



First off, some key discussion from the solr-user mailing list circa June 2014 
that should really be captured directly in this issue.

* 
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201406.mbox/%3CCAJc64EXgnPn-RiqgUYn=S_Wn5wPZsvtirEHP_nctZ-AFa=a...@mail.gmail.com%3E
* 
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201406.mbox/%3CCAE4tqLP-jqBjrWB0Yr2vNs8J15qW8BwVK61hZOG=__ejfpj...@mail.gmail.com%3E
* 
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201406.mbox/%3CCAJc64EVQP=asa6ofdsvpudcoea+-mo1usmlnfafjgp4oevb...@mail.gmail.com%3E

In particular these comments from Joel...

{quote}
So, the question is what is the cost (performance and memory) of having the
CollapsingQParserPlugin choose the group head by using the Solr sort
criteria?

Keep in mind that the CollapsingQParserPlugin's main design goal is to
provide fast performance when collapsing on a high cardinality field. How
you choose the group head can have a big impact here, both on memory
consumption performance.

The function query collapse criteria was added to allow you to come up with
custom formulas for selecting the group head, with little or no impact on
performance and memory. Using Solr's recip() function query it seems like
you could come up with some nice scenarios where two variables could be
used to select the group head. For example:

...
{quote}

And this respons from Umesh...

{quote}
...

I agree 200 MB per request just for collapsing the search results is huge
but at least it increases linearly with number of sort fields.. For my use
case, I am willing to pay the linear cost specially when I can't combine
the sort fields intelligently into a sort function. Plus it allows me to
sort by String/Text fields also which is a big win.

...
{quote}



Based on the total comments regarding this issue, including the email 
discussion, i've revised the summary & description to make it clear:

* this is a feature request
* that the goal is to expand the options available to users of the collapse 
QParser by allowing "group head" documents to be selected by more complex sort 
options


> ehance collapse QParser so that "group head" documents can be selected by 
> more complex sort options
> ---
>
> Key: SOLR-6168
> URL: https://issues.apache.org/jira/browse/SOLR-6168
>   

[jira] [Updated] (SOLR-6168) enhance collapse QParser so that "group head" documents can be selected by more complex sort options

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-6168:
---
Summary: enhance collapse QParser so that "group head" documents can be 
selected by more complex sort options  (was: ehance collapse QParser so that 
"group head" documents can be selected by more complex sort options)

> enhance collapse QParser so that "group head" documents can be selected by 
> more complex sort options
> 
>
> Key: SOLR-6168
> URL: https://issues.apache.org/jira/browse/SOLR-6168
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.7.1, 4.8.1
>Reporter: Umesh Prasad
>Assignee: Joel Bernstein
> Attachments: CollapsingQParserPlugin-6168.patch.1-1stcut, 
> SOLR-6168-group-head-inconsistent-with-sort.patch
>
>
> The fundemental goal of this issue is add additional support to the 
> CollapseQParser so that as an alternative to the existing min/max localparam 
> options, more robust sort syntax can be used to sort on multiple criteria 
> when selecting the "group head" documents used to represent each collapsed 
> group.
> Since support for arbitrary, multi-clause, sorting is almost certainly going 
> to require more RAM then the existing min/max functionaly, this new 
> functionality should be in addition to the existing min/max localparam 
> implementation, not a replacement of it.
> (NOTE: early comments made in this jira may be confusing in historical 
> context due to the way this issue was originally filed as a bug report)



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

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

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

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testArabicPDF

Error Message:
Invalid Date String:'Tue Mar 09 06:44:49 UTC 2010'

Stack Trace:
org.apache.solr.common.SolrException: Invalid Date String:'Tue Mar 09 06:44:49 
UTC 2010'
at 
__randomizedtesting.SeedInfo.seed([E67A23D330E513DC:88BC58DC3320B889]:0)
at org.apache.solr.util.DateFormatUtil.parseMath(DateFormatUtil.java:87)
at org.apache.solr.schema.TrieField.createField(TrieField.java:695)
at org.apache.solr.schema.TrieField.createFields(TrieField.java:732)
at 
org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:48)
at 
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:123)
at 
org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:83)
at 
org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:268)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:202)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:164)
at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:980)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:705)
at 
org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:104)
at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.doAdd(ExtractingDocumentLoader.java:122)
at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.addDoc(ExtractingDocumentLoader.java:127)
at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:230)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:151)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2079)
at 
org.apache.solr.util.TestHarness.queryAndResponse(TestHarness.java:339)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.loadLocalFromHandler(ExtractingRequestHandlerTest.java:737)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.loadLocal(ExtractingRequestHandlerTest.java:744)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testArabicPDF(ExtractingRequestHandlerTest.java:526)
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:504)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.car

[jira] [Updated] (LUCENE-6776) Randomized planet model shows up additional XYZBounds errors

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-6776:

Attachment: LUCENE-6776.patch

Patch with fix for GeoPath as well.  Now it beasts for a good long time without 
problems.  Final acceptance will, of course, require [~mikemccand]'s 
light-dimming Big Beaster to wale at it for a day, but... ;-)

> Randomized planet model shows up additional XYZBounds errors
> 
>
> Key: LUCENE-6776
> URL: https://issues.apache.org/jira/browse/LUCENE-6776
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Karl Wright
> Attachments: LUCENE-6776.patch, LUCENE-6776.patch, LUCENE-6776.patch
>
>
> Adding randomized PlanetModel construction causes points to be generated 
> inside a shape that are outside XYZBounds.  [~mikemccand] please take note.



--
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-6770) FSDirectory ctor should use getAbsolutePath instead of getRealPath for directory

[Vladimir Kuzmin (JIRA)]

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

Vladimir Kuzmin commented on LUCENE-6770:
-

Thanks, Uwe, I see obtainLock converts directory toRealPath anyway and adds 
then to concurent set LOCK_HELD. Do you mean tha NIO guarantees that call 
toRealPath will always return the same value even if link has changed? Is it 
documented behavior? Yes, we could add another method, like getLockDirectory 
and return toRealPath saved at ctor. My concern is that this all internal 
LOCK_HELD optimization looks useless and may even has some unpredictable 
behavior. I would always delegate it to system call. obtainLock tries to create 
lock file on every call, calls toRealPath, throws exception if failed to add to 
LOCK_HELD - it doesnt look like a solid optimization. In short, I would fix 
FSDirectory and remove static concurent set from NativeLockFactory at all. If 
obtainLock really needs optimization, we would need something like tryToObtain 
that returns true/false, check if Path is 'real', check LOCK_HELD before trying 
to create file. I can miss some historical reason though.

> FSDirectory ctor should use getAbsolutePath instead of getRealPath for 
> directory
> 
>
> Key: LUCENE-6770
> URL: https://issues.apache.org/jira/browse/LUCENE-6770
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Affects Versions: 5.2.1
> Environment: OS X, Linux
>Reporter: Vladimir Kuzmin
>Assignee: Uwe Schindler
> Attachments: LUCENE-6770.patch
>
>
> After upgrade from 4.1 to 5.2.1 I found that one of our test failed. Appeared 
> the guilty was FSDirectory that converts given Path to Path.getRealPath. As 
> result the test will fail:
> Path p = Paths.get("/var/lucene_store");
> FSDirectory d = new FSDirectory(p);
> assertEquals(p.toString(), d.getDirectory().toString());
> It because /var/lucene_store is a symlink and 
> Path directory =path.getRealPath(); 
> resolves it to /private/var/lucene_store
> I think this is bad design decision because "direcrory" isn't just internal 
> state but is exposed in a public interface and "getDirectory()" is widely 
> used to initialize other components. 
> It should use paths.getAbsolutePath() instead.
> build and "ant test" were successful after fix.



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

[Apache Jenkins Server]

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

3 tests failed.
REGRESSION:  org.apache.solr.client.solrj.impl.CloudSolrClientTest.test

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([963C8FFC680AC4A8:1E68B026C6F6A950]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.allTests(CloudSolrClientTest.java:257)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carr

Re: Permission to create cwiki page?

[Chris Hostetter]

: Not that I have anything immediate to update, but could I be added also?
: My username should be just "upayavira".

Also done.


-Hoss
http://www.lucidworks.com/

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

[jira] [Updated] (SOLR-8011) MapReduceIndexerTool uses 10^9 to convert nanos to seconds

[Mike Drob (JIRA)]

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

Mike Drob updated SOLR-8011:

Attachment: SOLR-8011.patch

Patch attached for trunk.

> MapReduceIndexerTool uses 10^9 to convert nanos to seconds
> --
>
> Key: SOLR-8011
> URL: https://issues.apache.org/jira/browse/SOLR-8011
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Reporter: Mike Drob
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-8011.patch
>
>
> MRIT incorrectly converts between nanos and seconds, inappropriately using a 
> bitwise operation instead of exponents.



--
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-8011) MapReduceIndexerTool uses 10^9 to convert nanos to seconds

[Mike Drob (JIRA)]

Mike Drob created SOLR-8011:
---

 Summary: MapReduceIndexerTool uses 10^9 to convert nanos to seconds
 Key: SOLR-8011
 URL: https://issues.apache.org/jira/browse/SOLR-8011
 Project: Solr
  Issue Type: Bug
  Components: contrib - MapReduce
Reporter: Mike Drob
Priority: Minor
 Fix For: Trunk


MRIT incorrectly converts between nanos and seconds, inappropriately using a 
bitwise operation instead of exponents.



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

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

Re: Permission to create cwiki page?

[Upayavira]

On Fri, Sep 4, 2015, at 10:15 PM, Gregory Chanan wrote:
> Hello,
>
> I'd like to add a page to the cwiki to document the ConfigSets API
> added in https://issues.apache.org/jira/browse/SOLR-7789.  I can't
> seem to find a "Create" button -- do I need permissions to be able to
> create a page?  My username on the cwiki is "gchanan" if someone is
> able to do that.
>
> Thanks, Greg

Not that I have anything immediate to update, but could I be added also?
My username should be just "upayavira".

Thanks!

Upayavira

Re: Permission to create cwiki page?

[Chris Hostetter]

you should be good to go.



-Hoss
http://www.lucidworks.com/

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

Permission to create cwiki page?

[Gregory Chanan]

Hello,

I'd like to add a page to the cwiki to document the ConfigSets API added in
https://issues.apache.org/jira/browse/SOLR-7789.  I can't seem to find a
"Create" button -- do I need permissions to be able to create a page?  My
username on the cwiki is "gchanan" if someone is able to do that.

Thanks,
Greg

[jira] [Commented] (LUCENE-6770) FSDirectory ctor should use getAbsolutePath instead of getRealPath for directory

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-6770:
-

Thanks for clarifying this, Uwe. Makes sense.

> FSDirectory ctor should use getAbsolutePath instead of getRealPath for 
> directory
> 
>
> Key: LUCENE-6770
> URL: https://issues.apache.org/jira/browse/LUCENE-6770
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Affects Versions: 5.2.1
> Environment: OS X, Linux
>Reporter: Vladimir Kuzmin
>Assignee: Uwe Schindler
> Attachments: LUCENE-6770.patch
>
>
> After upgrade from 4.1 to 5.2.1 I found that one of our test failed. Appeared 
> the guilty was FSDirectory that converts given Path to Path.getRealPath. As 
> result the test will fail:
> Path p = Paths.get("/var/lucene_store");
> FSDirectory d = new FSDirectory(p);
> assertEquals(p.toString(), d.getDirectory().toString());
> It because /var/lucene_store is a symlink and 
> Path directory =path.getRealPath(); 
> resolves it to /private/var/lucene_store
> I think this is bad design decision because "direcrory" isn't just internal 
> state but is exposed in a public interface and "getDirectory()" is widely 
> used to initialize other components. 
> It should use paths.getAbsolutePath() instead.
> build and "ant test" were successful after fix.



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

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

[jira] [Assigned] (LUCENE-6770) FSDirectory ctor should use getAbsolutePath instead of getRealPath for directory

[Uwe Schindler (JIRA)]

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

Uwe Schindler reassigned LUCENE-6770:
-

Assignee: Uwe Schindler

> FSDirectory ctor should use getAbsolutePath instead of getRealPath for 
> directory
> 
>
> Key: LUCENE-6770
> URL: https://issues.apache.org/jira/browse/LUCENE-6770
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Affects Versions: 5.2.1
> Environment: OS X, Linux
>Reporter: Vladimir Kuzmin
>Assignee: Uwe Schindler
> Attachments: LUCENE-6770.patch
>
>
> After upgrade from 4.1 to 5.2.1 I found that one of our test failed. Appeared 
> the guilty was FSDirectory that converts given Path to Path.getRealPath. As 
> result the test will fail:
> Path p = Paths.get("/var/lucene_store");
> FSDirectory d = new FSDirectory(p);
> assertEquals(p.toString(), d.getDirectory().toString());
> It because /var/lucene_store is a symlink and 
> Path directory =path.getRealPath(); 
> resolves it to /private/var/lucene_store
> I think this is bad design decision because "direcrory" isn't just internal 
> state but is exposed in a public interface and "getDirectory()" is widely 
> used to initialize other components. 
> It should use paths.getAbsolutePath() instead.
> build and "ant test" were successful after fix.



--
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-6770) FSDirectory ctor should use getAbsolutePath instead of getRealPath for directory

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-6770 at 9/4/15 7:27 PM:
---

The reason why we have the canonic path is the following: The 
NativeFSLockFactory has the limitation that the underlying OS does not lock 
files for the same process. It only prevents other processes from using the 
locked file/directory. So NativeFSLockFactory internally uses a static set of 
"locked index directories" and during aquiring locks it first checks if the 
given directory is in the set. If this is true it refuses to aquire lock. 
Otherwise it fall backs to OS kernel in checking the lock.
For this check with a simple set to work correctly, the path must be canonic. 
If this is not done, it may happen that a user opens in the same JVM an index 
with 2 different Path objects (which somehow point to same dir using 
symlink/hardlinks/junctions), causing index corrumption.
As getting canonic path is quite expensive, we dont expand it on every try to 
lock (which may also break if people change links while having index open). So 
we do it on FSDirectory init.
To work around the issue mentioned here, one possibility would be to save the 
original Path as given in Ctor and return that one getDirectory(). The canonic 
path would be an implementation detail.


was (Author: thetaphi):
The reason why we have the canonic path is the following: The 
NativeFSLockFactory has the limitation that the underlying OS does not lock 
files for the same process. It only prevents other processes from using the 
locked file/directory. So NativeFSLockFactory internally uses a static set of 
"locked index directories" and during aquiring locks it first checks if the 
given directory is in the set. If this is true it refuses to aquire lock. 
Otherwise it fall backs to OS kernel in checking the lock.
For this check with a simple set to work correctly, the path must be canonic. 
If this is not done, it may happen that a user opens in the same JVM an index 
with 2 different Path objects (which somehow point to same dir using 
symlink/hardlinks/junctions), leading broken indexes.
As getting canonic path is quite expensive, we dont expand it on every try to 
lock (which may also break if people change links while having index open). So 
we do it on FSDirectory init.
To work around the issue mentioned here, one possibility would be to save the 
original Path as given in Ctor and return that one getDirectory(). The canonic 
path would be an implementation detail.

> FSDirectory ctor should use getAbsolutePath instead of getRealPath for 
> directory
> 
>
> Key: LUCENE-6770
> URL: https://issues.apache.org/jira/browse/LUCENE-6770
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Affects Versions: 5.2.1
> Environment: OS X, Linux
>Reporter: Vladimir Kuzmin
> Attachments: LUCENE-6770.patch
>
>
> After upgrade from 4.1 to 5.2.1 I found that one of our test failed. Appeared 
> the guilty was FSDirectory that converts given Path to Path.getRealPath. As 
> result the test will fail:
> Path p = Paths.get("/var/lucene_store");
> FSDirectory d = new FSDirectory(p);
> assertEquals(p.toString(), d.getDirectory().toString());
> It because /var/lucene_store is a symlink and 
> Path directory =path.getRealPath(); 
> resolves it to /private/var/lucene_store
> I think this is bad design decision because "direcrory" isn't just internal 
> state but is exposed in a public interface and "getDirectory()" is widely 
> used to initialize other components. 
> It should use paths.getAbsolutePath() instead.
> build and "ant test" were successful after fix.



--
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-6770) FSDirectory ctor should use getAbsolutePath instead of getRealPath for directory

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6770:
---

The reason why we have the canonic path is the following: The 
NativeFSLockFactory has the limitation that the underlying OS does not lock 
files for the same process. It only prevents other processes from using the 
locked file/directory. So NativeFSLockFactory internally uses a static set of 
"locked index directories" and during aquiring locks it first checks if the 
given directory is in the set. If this is true it refuses to aquire lock. 
Otherwise it fall backs to OS kernel in checking the lock.
For this check with a simple set to work correctly, the path must be canonic. 
If this is not done, it may happen that a user opens in the same JVM an index 
with 2 different Path objects (which somehow point to same dir using 
symlink/hardlinks/junctions), leading broken indexes.
As getting canonic path is quite expensive, we dont expand it on every try to 
lock (which may also break if people change links while having index open). So 
we do it on FSDirectory init.
To work around the issue mentioned here, one possibility would be to save the 
original Path as given in Ctor and return that one getDirectory(). The canonic 
path would be an implementation detail.

> FSDirectory ctor should use getAbsolutePath instead of getRealPath for 
> directory
> 
>
> Key: LUCENE-6770
> URL: https://issues.apache.org/jira/browse/LUCENE-6770
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Affects Versions: 5.2.1
> Environment: OS X, Linux
>Reporter: Vladimir Kuzmin
> Attachments: LUCENE-6770.patch
>
>
> After upgrade from 4.1 to 5.2.1 I found that one of our test failed. Appeared 
> the guilty was FSDirectory that converts given Path to Path.getRealPath. As 
> result the test will fail:
> Path p = Paths.get("/var/lucene_store");
> FSDirectory d = new FSDirectory(p);
> assertEquals(p.toString(), d.getDirectory().toString());
> It because /var/lucene_store is a symlink and 
> Path directory =path.getRealPath(); 
> resolves it to /private/var/lucene_store
> I think this is bad design decision because "direcrory" isn't just internal 
> state but is exposed in a public interface and "getDirectory()" is widely 
> used to initialize other components. 
> It should use paths.getAbsolutePath() instead.
> build and "ant test" were successful after fix.



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

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

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

[Apache Jenkins Server]

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

5 tests failed.
REGRESSION:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test

Error Message:
shard1 is not consistent.  Got 79 from 
http://127.0.0.1:49987/_t/e/collection1lastClient and got 68 from 
http://127.0.0.1:59523/_t/e/collection1

Stack Trace:
java.lang.AssertionError: shard1 is not consistent.  Got 79 from 
http://127.0.0.1:49987/_t/e/collection1lastClient and got 68 from 
http://127.0.0.1:59523/_t/e/collection1
at 
__randomizedtesting.SeedInfo.seed([E1ADC472F7E85B9C:69F9FBA859143664]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1246)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1225)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:165)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 

Re: Can no longer override IndexConfig values in solrconfig.xml?

[Mark Miller]

Really, I was already pretty sure that there was nothing else specifying
the lock factory because I saw that the lock factory was not being set
right, even though HdfsTestUtil was setting it as: solr.lock.type=hdfs

That xml snippet now seems to have solr.tests.lockType instead of
solr.lock.type though. So that was the problem. I will add a check to an
hdfs test to make sure the right lock factory gets set via config.

I'm sure I've been by the includes before, but same as this time, I ignored
what I didn't recognize - XML has a bunch of junk I'm used to glazing over.

- Mark

On Fri, Sep 4, 2015 at 1:49 PM Mark Miller  wrote:

> Not messing with anything in indexconfig I guess.
>
> - Mark
>
> On Fri, Sep 4, 2015 at 1:37 PM Chris Hostetter 
> wrote:
>
>>
>> : I was not up to date on this:
>> :
>> : http://www.w3.org/2001/XInclude"/>
>> :
>> : First XML include I've ever seen in practice.
>>
>> dude... that's been in all solr (core) tests since summer 2013.
>>
>> where you been?
>>
>>
>>
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>> --
> - Mark
> about.me/markrmiller
>
-- 
- Mark
about.me/markrmiller

Re: Can no longer override IndexConfig values in solrconfig.xml?

[Mark Miller]

Not messing with anything in indexconfig I guess.

- Mark

On Fri, Sep 4, 2015 at 1:37 PM Chris Hostetter 
wrote:

>
> : I was not up to date on this:
> :
> : http://www.w3.org/2001/XInclude"/>
> :
> : First XML include I've ever seen in practice.
>
> dude... that's been in all solr (core) tests since summer 2013.
>
> where you been?
>
>
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
- Mark
about.me/markrmiller

Re: Can no longer override IndexConfig values in solrconfig.xml?

[Chris Hostetter]

: I was not up to date on this:
: 
: http://www.w3.org/2001/XInclude"/>
: 
: First XML include I've ever seen in practice.

dude... that's been in all solr (core) tests since summer 2013.  

where you been?




-Hoss
http://www.lucidworks.com/

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

Re: Can no longer override IndexConfig values in solrconfig.xml?

[Mark Miller]

I was not up to date on this:

http://www.w3.org/2001/XInclude"/>

First XML include I've ever seen in practice.

- Mark

On Fri, Sep 4, 2015 at 1:32 PM Chris Hostetter 
wrote:

> : On trunk, when I add the following to the solrconfig.xml, I can't load a
> : SolrCore. What am I doing wrong?
> ...
> : There is only the indexConfig I have added.
>
> are you sure?
>
> file a bug and attach your entire solr home dir, because i can't reproduce
> with the following configs -- the core loads just fine...
>
>
> 
> 
>   6.0.0
>   
> ${solr.lock.type:native}
>   
> 
>
> 
> 
>
>
> required="true" multiValued="false" />
>id
>
> positionIncrementGap="0"/>
> 
>
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
- Mark
about.me/markrmiller

Re: Can no longer override IndexConfig values in solrconfig.xml?

[Chris Hostetter]

: On trunk, when I add the following to the solrconfig.xml, I can't load a
: SolrCore. What am I doing wrong?
... 
: There is only the indexConfig I have added.

are you sure?

file a bug and attach your entire solr home dir, because i can't reproduce 
with the following configs -- the core loads just fine...




  6.0.0
  
${solr.lock.type:native}
  




   
   

   id
   
   




-Hoss
http://www.lucidworks.com/

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

Re: Can no longer override IndexConfig values in solrconfig.xml?

[Mark Miller]

I see - we have XML includes now. This in another file.

- Mark

On Fri, Sep 4, 2015 at 1:21 PM Mark Miller  wrote:

> On trunk, when I add the following to the solrconfig.xml, I can't load a
> SolrCore. What am I doing wrong?
>
> 
> ${solr.lock.type:native}
> 
>
> Caused by: org.apache.solr.common.SolrException: solrconfig.xml contains
> more than one value for config path: indexConfig
> at org.apache.solr.core.Config.getNode(Config.java:275)
> at org.apache.solr.core.Config.getNode(Config.java:252)
> at org.apache.solr.update.SolrIndexConfig.(SolrIndexConfig.java:114)
> at org.apache.solr.core.SolrConfig.(SolrConfig.java:229)
> at
> org.apache.solr.core.SolrConfig.readFromResourceLoader(SolrConfig.java:176)
> ... 10 more
>
> There is only the indexConfig I have added.
>
> - Mark
> --
> - Mark
> about.me/markrmiller
>
-- 
- Mark
about.me/markrmiller

Can no longer override IndexConfig values in solrconfig.xml?

[Mark Miller]

On trunk, when I add the following to the solrconfig.xml, I can't load a
SolrCore. What am I doing wrong?


${solr.lock.type:native}


Caused by: org.apache.solr.common.SolrException: solrconfig.xml contains
more than one value for config path: indexConfig
at org.apache.solr.core.Config.getNode(Config.java:275)
at org.apache.solr.core.Config.getNode(Config.java:252)
at org.apache.solr.update.SolrIndexConfig.(SolrIndexConfig.java:114)
at org.apache.solr.core.SolrConfig.(SolrConfig.java:229)
at
org.apache.solr.core.SolrConfig.readFromResourceLoader(SolrConfig.java:176)
... 10 more

There is only the indexConfig I have added.

- Mark
-- 
- Mark
about.me/markrmiller

[jira] [Commented] (SOLR-8007) TestSearcherReuse failure

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8007:
--

Yonik, in case you hadn't seen it, SOLR-7611 has some more details about 
TestSearcherReuse issues.

> TestSearcherReuse failure
> -
>
> Key: SOLR-8007
> URL: https://issues.apache.org/jira/browse/SOLR-8007
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-8007.patch
>
>
> Reproducible fail:
> {code}
> ant test  -Dtestcase=TestSearcherReuse -Dtests.method=test 
> -Dtests.seed=A152E85315C87BD2 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=es_EC -Dtests.timezone=Atlantic/South_Georgia 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
> {code}



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

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

[jira] [Resolved] (SOLR-7611) TestSearcherReuse failure

[Yonik Seeley (JIRA)]

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

Yonik Seeley resolved SOLR-7611.

Resolution: Fixed

Sorry folks - didn't see this issue before I opened the other one.
Anyway, my failure was due to background merges completing after the first 
commit, causing the second commit to have changes.

I assume it's the same case here.  The seed here no longer fails either, so I 
think we can close.

> TestSearcherReuse failure
> -
>
> Key: SOLR-7611
> URL: https://issues.apache.org/jira/browse/SOLR-7611
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.2
>Reporter: Steve Rowe
> Attachments: SOLR-7611_test.patch, typescript
>
>
> {noformat}
>[junit4] FAILURE 0.94s | TestSearcherReuse.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected 
> same: main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_0(5.2.0):C3)
>  Uninverting(_2(5.2.0):c2)))}> was not: main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_0(5.2.0):C3)
>  Uninverting(_2(5.2.0):c2)))}>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([F1A11DF972B907D6:79F52223DC456A2E]:0)
>[junit4]>  at 
> org.apache.solr.search.TestSearcherReuse.assertSearcherHasNotChanged(TestSearcherReuse.java:247)
>[junit4]>  at 
> org.apache.solr.search.TestSearcherReuse.test(TestSearcherReuse.java:104)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Reproduces for me on the 5.2 release branch with the following - note that 
> both {{-Dtests.multiplier=2}} and {{-Dtests.nightly=true}} are required to 
> reproduce:
> {noformat}
> ant test  -Dtestcase=TestSearcherReuse -Dtests.seed=F1A11DF972B907D6 
> -Dtests.multiplier=2 -Dtests.nightly=true
> {noformat}
> Full log:
> {noformat}
>[junit4]  says hallo! Master seed: F1A11DF972B907D6
>[junit4] Executing 1 suite with 1 JVM.
>[junit4] 
>[junit4] Started J0 PID(776@smb.local).
>[junit4] Suite: org.apache.solr.search.TestSearcherReuse
>[junit4]   2> log4j:WARN No such property [conversionPattern] in 
> org.apache.solr.util.SolrLogLayout.
>[junit4]   2> Creating dataDir: 
> /Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_2/solr/build/solr-core/test/J0/temp/solr.search.TestSearcherReuse
>  F1A11DF972B907D6-002/init-core-data-001
>[junit4]   2> 889 T11 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl 
> (false) and clientAuth (false)
>[junit4]   2> 959 T11 oas.SolrTestCaseJ4.initCore initCore
>[junit4]   2> 1093 T11 oasc.SolrResourceLoader. new 
> SolrResourceLoader for directory: 
> '/Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_2/solr/build/solr-core/test/J0/temp/solr.search.TestSearcherReuse
>  F1A11DF972B907D6-002/tempDir-001/collection1/'
>[junit4]   2> 1390 T11 oasc.SolrConfig.refreshRequestParams current 
> version of requestparams : -1
>[junit4]   2> 1449 T11 oasc.SolrConfig. Using Lucene MatchVersion: 
> 5.2.0
>[junit4]   2> 1551 T11 oasc.SolrConfig. Loaded SolrConfig: 
> solrconfig-managed-schema.xml
>[junit4]   2> 1563 T11 oass.ManagedIndexSchemaFactory.readSchemaLocally 
> The schema is configured as managed, but managed schema resource 
> managed-schema not found - loading non-managed schema 
> schema-id-and-version-fields-only.xml instead
>[junit4]   2> 1580 T11 oass.IndexSchema.readSchema Reading Solr Schema 
> from 
> /Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_2/solr/build/solr-core/test/J0/temp/solr.search.TestSearcherReuse
>  
> F1A11DF972B907D6-002/tempDir-001/collection1/conf/schema-id-and-version-fields-only.xml
>[junit4]   2> 1594 T11 oass.IndexSchema.readSchema [null] Schema 
> name=id-and-version-fields-only
>[junit4]   2> 1676 T11 oass.IndexSchema.readSchema unique key field: id
>[junit4]   2> 1706 T11 oass.ManagedIndexSchema.persistManagedSchema 
> Upgraded to managed schema at 
> /Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_2/solr/build/solr-core/test/J0/temp/solr.search.TestSearcherReuse
>  F1A11DF972B907D6-002/tempDir-001/collection1/conf/managed-schema
>[junit4]   2> 1709 T11 
> oass.ManagedIndexSchemaFactory.upgradeToManagedSchema After upgrading to 
> managed schema, renamed the non-managed schema 
> /Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_2/solr/build/solr-core/test/J0/temp/solr.search.TestSearcherReuse
>  
> F1A11DF972B907D6-002/tempDir-001/collection1/conf/schema-id-and-version-fields-only.xml
>  to 
> /Users/sarowe/svn/lucene/dev/branches/lucene_solr_5_2/solr/build/solr-core/test/J0/temp/solr.search.TestSearcherReuse
>  
> F1A11DF972B907D6-002/tempDir-001/collection1/conf/schema-id-and-version-fields-only.xml.bak
>[junit4]   2> 1714 T11 oasc.SolrResourceLoader.locateSolrHome JNDI not 
> configured for solr (NoInitialContextEx)
>[junit4] 

[jira] [Commented] (LUCENE-6776) Randomized planet model shows up additional XYZBounds errors

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-6776:
-

Thanks-- was able to construct a simple test case that demonstrated the 
problem.  Now, back to debugging...


> Randomized planet model shows up additional XYZBounds errors
> 
>
> Key: LUCENE-6776
> URL: https://issues.apache.org/jira/browse/LUCENE-6776
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Karl Wright
> Attachments: LUCENE-6776.patch, LUCENE-6776.patch
>
>
> Adding randomized PlanetModel construction causes points to be generated 
> inside a shape that are outside XYZBounds.  [~mikemccand] please take note.



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

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

[jira] [Resolved] (SOLR-8007) TestSearcherReuse failure

[Yonik Seeley (JIRA)]

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

Yonik Seeley resolved SOLR-8007.

   Resolution: Fixed
Fix Version/s: 5.4
   Trunk

> TestSearcherReuse failure
> -
>
> Key: SOLR-8007
> URL: https://issues.apache.org/jira/browse/SOLR-8007
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-8007.patch
>
>
> Reproducible fail:
> {code}
> ant test  -Dtestcase=TestSearcherReuse -Dtests.method=test 
> -Dtests.seed=A152E85315C87BD2 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=es_EC -Dtests.timezone=Atlantic/South_Georgia 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
> {code}



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

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

[jira] [Assigned] (SOLR-8007) TestSearcherReuse failure

[Yonik Seeley (JIRA)]

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

Yonik Seeley reassigned SOLR-8007:
--

Assignee: Yonik Seeley

> TestSearcherReuse failure
> -
>
> Key: SOLR-8007
> URL: https://issues.apache.org/jira/browse/SOLR-8007
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-8007.patch
>
>
> Reproducible fail:
> {code}
> ant test  -Dtestcase=TestSearcherReuse -Dtests.method=test 
> -Dtests.seed=A152E85315C87BD2 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=es_EC -Dtests.timezone=Atlantic/South_Georgia 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
> {code}



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

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

[jira] [Commented] (SOLR-8007) TestSearcherReuse failure

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8007: tests: fix TestSearcherReuse by avoiding background merges

> TestSearcherReuse failure
> -
>
> Key: SOLR-8007
> URL: https://issues.apache.org/jira/browse/SOLR-8007
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
> Attachments: SOLR-8007.patch
>
>
> Reproducible fail:
> {code}
> ant test  -Dtestcase=TestSearcherReuse -Dtests.method=test 
> -Dtests.seed=A152E85315C87BD2 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=es_EC -Dtests.timezone=Atlantic/South_Georgia 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
> {code}



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

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

[jira] [Commented] (SOLR-8007) TestSearcherReuse failure

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8007: tests: fix TestSearcherReuse by avoiding background merges

> TestSearcherReuse failure
> -
>
> Key: SOLR-8007
> URL: https://issues.apache.org/jira/browse/SOLR-8007
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
> Attachments: SOLR-8007.patch
>
>
> Reproducible fail:
> {code}
> ant test  -Dtestcase=TestSearcherReuse -Dtests.method=test 
> -Dtests.seed=A152E85315C87BD2 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=es_EC -Dtests.timezone=Atlantic/South_Georgia 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
> {code}



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

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

[jira] [Updated] (SOLR-8007) TestSearcherReuse failure

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-8007:
---
Attachment: SOLR-8007.patch

OK, so it was a test bug.
IW.hasUncommittedChanges() *can* return true after commit has been called 
because of pending merges.

Patch attached that changes the commit to an optimize to prevent this.


> TestSearcherReuse failure
> -
>
> Key: SOLR-8007
> URL: https://issues.apache.org/jira/browse/SOLR-8007
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
> Attachments: SOLR-8007.patch
>
>
> Reproducible fail:
> {code}
> ant test  -Dtestcase=TestSearcherReuse -Dtests.method=test 
> -Dtests.seed=A152E85315C87BD2 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=es_EC -Dtests.timezone=Atlantic/South_Georgia 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
> {code}



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

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

[jira] [Commented] (LUCENE-6776) Randomized planet model shows up additional XYZBounds errors

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6776:


bq. So I really do need repeatability here to make any progress.

Argh, we are simply hitting this long ago known issue: LUCENE-6194.

The workaround (I think?) is to simply add back the {{-Dtests.iters=10}} that 
you had originally specified to {{ant beast}}, but you also must add a wildcard 
* at the end of the {{-Dtests.name=XXX}}.  E.g. I just hit a failure with your 
{{ant beast}} line, confirmed the {{Reproduce with}} line is buggy (does not in 
fact reproduce) but then added back the iters and the {{*}} and it does 
reproduce:

{noformat}
ant test  -Dtestcase=TestGeo3DPointField -Dtests.method=testGeo3DRelations* 
-Dtests.seed=B8B6B22C45AFEE9F -Dtests.locale=ms_MY 
-Dtests.timezone=America/Moncton -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII -Dtests.iters=10
{noformat}

causes:

{noformat}
   [junit4] FAILURE 0.33s | TestGeo3DPointField.testGeo3DRelations {#7 
seed=[B8B6B22C45AFEE9F:7CCEE6732E8A91DE]} <<<
   [junit4]> Throwable #1: java.lang.AssertionError: invalid hits for 
shape=GeoPath: {planetmodel=PlanetModel(ab=1.151145876105594 
c=0.8488541238944061), width=0.008726646259971648(0.5), 
points={[[lat=-0.6925658899376476, lon=0.6316613927914589], 
[lat=0.27828548161836364, lon=0.6785795524104564]]}}
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([B8B6B22C45AFEE9F:7CCEE6732E8A91DE]:0)
   [junit4]>at 
org.apache.lucene.bkdtree3d.TestGeo3DPointField.testGeo3DRelations(TestGeo3DPointField.java:708)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4] OK  1.64s | TestGeo3DPointField.testGeo3DRelations {#8 
seed=[B8B6B22C45AFEE9F:4E62031D59418684]}
   [junit4] OK  0.98s | TestGeo3DPointField.testGeo3DRelations {#9 
seed=[B8B6B22C45AFEE9F:99E955A73D16B1D6]}
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene53): {}, 
docValues:{}, sim=RandomSimilarityProvider(queryNorm=true,coord=crazy): {}, 
locale=ms_MY, timezone=America/Moncton
   [junit4]   2> NOTE: Linux 3.13.0-61-generic amd64/Oracle Corporation 
1.8.0_40 (64-bit)/cpus=8,threads=1,free=455977424,total=471859200
   [junit4]   2> NOTE: All tests run in this JVM: [TestGeo3DPointField]
   [junit4] Completed [1/1] in 7.14s, 10 tests, 1 failure <<< FAILURES!
{noformat}

> Randomized planet model shows up additional XYZBounds errors
> 
>
> Key: LUCENE-6776
> URL: https://issues.apache.org/jira/browse/LUCENE-6776
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Karl Wright
> Attachments: LUCENE-6776.patch, LUCENE-6776.patch
>
>
> Adding randomized PlanetModel construction causes points to be generated 
> inside a shape that are outside XYZBounds.  [~mikemccand] please take note.



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

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

[jira] [Resolved] (LUCENE-6772) MultiCollector should catch CollectionTerminatedException

[Adrien Grand (JIRA)]

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

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

> MultiCollector should catch CollectionTerminatedException
> -
>
> Key: LUCENE-6772
> URL: https://issues.apache.org/jira/browse/LUCENE-6772
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6772.patch
>
>
> If you wrap two collectors in a MultiCollector and one of them terminates 
> early, then it will also make the other one terminate since MultiCollector 
> propagates the CollectionTerminatedException.



--
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-6777) Switch GeoPointTermsEnum range list to use a reusable BytesRef

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6777:


bq. So it continues to grow the byte array for whatever reused buffer is passed.

Hmm but that grow is (effectively: a couple if statements) a no-op if the 
builder's {{byte[]}} is already large enough?

That {{NumericUtils}} encoding code is so hairy, I really don't think we want 
it in more places than one!

Also, the check for {{reusable == null}} isn't needed?  It can become {{assert 
reusable != null}}, and maybe rename {{reusable}} to {{result}}?

> Switch GeoPointTermsEnum range list to use a reusable BytesRef 
> ---
>
> Key: LUCENE-6777
> URL: https://issues.apache.org/jira/browse/LUCENE-6777
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6777.patch, LUCENE-6777.patch, LUCENE-6777.patch
>
>
> GeoPointTermsEnum currently constructs a BytesRef for every computed range, 
> then sorts on this BytesRef.  This adds an unnecessary memory overhead since 
> the TermsEnum only requires BytesRef on calls to nextSeekTerm and accept and 
> the ranges only need to be sorted by their long representation. This issue 
> adds the following two improvements:
> 1. Lazily compute the BytesRef on demand only when its needed
> 2. Add a single, transient BytesRef to GeoPointTermsEnum
> This will further cut back on heap usage when constructing ranges across 
> every segment.



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

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

Re: Apache Lucene Update 2015-09-04

[Michael McCandless]

You're welcome!

Mike McCandless

http://blog.mikemccandless.com


On Fri, Sep 4, 2015 at 11:07 AM, david.w.smi...@gmail.com
 wrote:
> Thanks for this Mike :-)
>
> On Fri, Sep 4, 2015 at 11:02 AM Michael McCandless  wrote:
>>
>> Lucene summary for this week:
>>
>> A 5.3.1 bugfix release may be coming soon
>>
>> See the confusion matrix for a classifier
>>
>> Remove a nasty classloader hack that broke MorfologikFilter , and fix it
>> correctly so you can pass the dictionary as a URI
>>
>> The new BoostQuery decouples Query from boosting, but it was missing its
>> rewrite method
>>
>> How can we compress postings payloads?
>>
>> Nested conjunctions should always be flattened
>>
>> MultiCollector did not handle early termination properly
>>
>> Add a point-within-distance query implemented with BKD trees
>>
>> Speed up IndexSearcher.count when a query is so simple (match all, single
>> term) that we can use index statistics instead
>>
>> The integration of BKDTree and Geo3D is done (for Lucene 5.4.0), providing
>> accurate and fast earth-surface "point in shape" queries, but we need to
>> make its randomized tests more evil by simulating planets more squashed than
>> earth, requiring somecrazy math, including Lagrange multipliers
>>
>> GeoPointDistanceQuery is buggy with large distances
>>
>> Don't use approximations for MatchAllDocsQuery, and give it a dedicated
>> BulkScorer
>>
>> Dodge bugs in Java's collators
>>
>> Windows NTFS pending delete state for a file causes assertion failures in
>> Lucene; we should fix Lucene's WindowsFS to also simulate this state
>>
>> Symlinks to an index directory continue to cause problems for users
>>
>> CheckIndex cannot handle corrupt .si files
>>
>> Reduce heap used by CompressingStoredFieldsWriter when writing large
>> strings during indexing
>>
>> Reduce heap used by the new geo point queries by building the BytesRef on
>> demand for sub-ranges
>>
>> GeoPointDistanceRangeQuery will match points within a min/max distance
>> range
>>
>> When you incorrectly index nested documents the resulting error messages
>> are very confusing
>>
>> DisjunctionMaxQuery, BoostingQuery and BoostedQuery now use IndexSearcher
>> to create sub-weights so caching can apply
>>
>> Mike McCandless
>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com

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

[jira] [Commented] (LUCENE-6776) Randomized planet model shows up additional XYZBounds errors

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-6776:
-

These turn out to be another series of "the point should be a hit but isn't" 
failures.

I tried to reproduce it with the information I could print at the time of the 
actual failure, and checked whether the XYZBound that was computed was correct. 
 It was.  So I really *do* need repeatability here to make any progress.

> Randomized planet model shows up additional XYZBounds errors
> 
>
> Key: LUCENE-6776
> URL: https://issues.apache.org/jira/browse/LUCENE-6776
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Karl Wright
> Attachments: LUCENE-6776.patch, LUCENE-6776.patch
>
>
> Adding randomized PlanetModel construction causes points to be generated 
> inside a shape that are outside XYZBounds.  [~mikemccand] please take note.



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

Error Message:
expected:<200> but was:<403>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<403>
at 
__randomizedtesting.SeedInfo.seed([83E1EBDA317561CF:BE3945F6099B3FBF]: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.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:144)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:198)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.

[jira] [Commented] (SOLR-7836) Possible deadlock when closing refcounted index writers.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-7836:
--

[~ysee...@gmail.com]] re: back-porting to 5.3.1. Never mind...

I just checked to be sure. Noble cut the 5.3 branch 3 days _before_ my first 
checkin for this ticket. If the problems you found with that check in were in 
the release a back-port was in order. But  since they're not, I see no need.

> Possible deadlock when closing refcounted index writers.
> 
>
> Key: SOLR-7836
> URL: https://issues.apache.org/jira/browse/SOLR-7836
> Project: Solr
>  Issue Type: Bug
>Reporter: Erick Erickson
>Assignee: Yonik Seeley
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-7836-reorg.patch, SOLR-7836-synch.patch, 
> SOLR-7836.patch, SOLR-7836.patch, SOLR-7836.patch, SOLR-7836.patch, 
> SOLR-7836.patch, deadlock_3.res.zip, deadlock_5_pass_iw.res.zip, deadlock_test
>
>
> Preliminary patch for what looks like a possible race condition between 
> writerFree and pauseWriter in DefaultSorlCoreState.
> Looking for comments and/or why I'm completely missing the boat.



--
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-6776) Randomized planet model shows up additional XYZBounds errors

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-6776:
-

Tried dropping numThreads in verify() to 1.  Didn't help with reproducibility, 
unfortunately.


> Randomized planet model shows up additional XYZBounds errors
> 
>
> Key: LUCENE-6776
> URL: https://issues.apache.org/jira/browse/LUCENE-6776
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Karl Wright
> Attachments: LUCENE-6776.patch, LUCENE-6776.patch
>
>
> Adding randomized PlanetModel construction causes points to be generated 
> inside a shape that are outside XYZBounds.  [~mikemccand] please take note.



--
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-8010) Allow WordBreakSolrSpellChecker to break when one word matches

[Joshua Edwards (JIRA)]

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

Joshua Edwards commented on SOLR-8010:
--

Attached a patch file, as well as creating a pull request to the lucene_4_10 
branch.  The changes should be able to be easily integrated into trunk as well 
(though I have not done that since we are currently using 4_10_X).

> Allow WordBreakSolrSpellChecker to break when one word matches
> --
>
> Key: SOLR-8010
> URL: https://issues.apache.org/jira/browse/SOLR-8010
> Project: Solr
>  Issue Type: Improvement
>  Components: spellchecker
>Affects Versions: 4.10.4, 5.3
>Reporter: Joshua Edwards
> Attachments: WordBreakDontRequireWordOnBothSides.patch
>
>
> The WordBreakSolrSpellChecker only works if both words that are being broken 
> are in the dictionary.  This prevents the spell checker from breaking in 
> other valid use cases - such as when one of the words has a synonym that is 
> in the dictionary, or when one of the words is misspelled.  I would like to 
> enable (via configuration) the option to break when one of the two words is 
> in the dictionary, but the other is not.  



--
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-8010) Allow WordBreakSolrSpellChecker to break when one word matches

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8010:
--

GitHub user Admje14 opened a pull request:

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

JIRA: SOLR-8010 - Adding the ability to configure an option to break …

…words when the right or left side of a break is a word, but not both.



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

$ git pull https://github.com/Admje14/lucene-solr lucene_solr_4_10

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

https://github.com/apache/lucene-solr/pull/200.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 #200


commit 26aacab65676d7d301527d70426f982cc376a2c4
Author: Josh Edwards 
Date:   2015-09-04T15:15:51Z

JIRA: SOLR-8010 - Adding the ability to configure an option to break words 
when the right or left side of a break is a word, but not both.




> Allow WordBreakSolrSpellChecker to break when one word matches
> --
>
> Key: SOLR-8010
> URL: https://issues.apache.org/jira/browse/SOLR-8010
> Project: Solr
>  Issue Type: Improvement
>  Components: spellchecker
>Affects Versions: 4.10.4, 5.3
>Reporter: Joshua Edwards
> Attachments: WordBreakDontRequireWordOnBothSides.patch
>
>
> The WordBreakSolrSpellChecker only works if both words that are being broken 
> are in the dictionary.  This prevents the spell checker from breaking in 
> other valid use cases - such as when one of the words has a synonym that is 
> in the dictionary, or when one of the words is misspelled.  I would like to 
> enable (via configuration) the option to break when one of the two words is 
> in the dictionary, but the other is not.  



--
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: JIRA: SOLR-8010 - Adding the ability to ...

[Admje14]

GitHub user Admje14 opened a pull request:

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

JIRA: SOLR-8010 - Adding the ability to configure an option to break …

…words when the right or left side of a break is a word, but not both.



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

$ git pull https://github.com/Admje14/lucene-solr lucene_solr_4_10

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

https://github.com/apache/lucene-solr/pull/200.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 #200


commit 26aacab65676d7d301527d70426f982cc376a2c4
Author: Josh Edwards 
Date:   2015-09-04T15:15:51Z

JIRA: SOLR-8010 - Adding the ability to configure an option to break words 
when the right or left side of a break is a word, but not both.




---
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] [Commented] (LUCENE-6776) Randomized planet model shows up additional XYZBounds errors

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-6776:
-

This is what I've been doing:

{code}
ant beast -Dbeast.iters=100 -Dtestcase=TestGeo3DPointField 
-Dtestmethod=testGeo3DRelations -Dtests.dups=6 -Dtests.iters=10 >capture 
2>capture2
{code}

> Randomized planet model shows up additional XYZBounds errors
> 
>
> Key: LUCENE-6776
> URL: https://issues.apache.org/jira/browse/LUCENE-6776
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Karl Wright
> Attachments: LUCENE-6776.patch, LUCENE-6776.patch
>
>
> Adding randomized PlanetModel construction causes points to be generated 
> inside a shape that are outside XYZBounds.  [~mikemccand] please take note.



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

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

Re: Apache Lucene Update 2015-09-04

[david.w.smi...@gmail.com]

Thanks for this Mike :-)

On Fri, Sep 4, 2015 at 11:02 AM Michael McCandless  wrote:

> Lucene summary for this week:
>
>- A 5.3.1 bugfix release may be coming soon
>
>
>- See the confusion matrix
> for a classifier
>
>- Remove a nasty classloader hack that broke MorfologikFilter
>, and fix it
>correctly  so you
>can pass the dictionary as a URI
>
>- The new BoostQuery decouples Query from boosting
>, but it was
>missing its rewrite method
>
>
>- How can we compress postings payloads
>?
>
>- Nested conjunctions should always be flattened
>
>
>- MultiCollector did not handle early termination properly
>
>
>- Add a point-within-distance query
> implemented with
>BKD trees
>
>- Speed up IndexSearcher.count
>when a query is so
>simple (match all, single term) that we can use index statistics instead
>
>- The integration of BKDTree and Geo3D
>is done (for Lucene
>5.4.0), providing accurate and fast earth-surface "point in shape" queries,
>but we need to make its randomized tests more evil by simulating
>planets more squashed than earth
>, requiring somecrazy
>math
>
> ,
>including Lagrange multipliers
>
>
>- GeoPointDistanceQuery is buggy with large distances
>
>
>- Don't use approximations
> for
>MatchAllDocsQuery, and give it a dedicated BulkScorer
>
>
>- Dodge bugs in Java's collators
>
>
>- Windows NTFS pending delete state for a file
> causes assertion
>failures in Lucene; we should fix Lucene's WindowsFS to also simulate
>this state 
>
>- Symlinks to an index directory continue to cause problems for users
>
>
>- CheckIndex cannot handle corrupt .si
>files
>
>- Reduce heap used by
>
>CompressingStoredFieldsWriter when writing large strings during
>indexing
>
>- Reduce heap used by
> the new geo point
>queries by building the BytesRef on demand for sub-ranges
>
>- GeoPointDistanceRangeQuery will match points within a min/max
>distance range 
>
>- When you incorrectly index nested documents the resulting error
>messages are very confusing
>
>
>- DisjunctionMaxQuery, BoostingQuery and BoostedQuery now use
>IndexSearcher to create sub-weights
> so caching can
>apply
>
> Mike McCandless
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Apache Lucene Update 2015-09-04

[Michael McCandless]

Lucene summary for this week:

   - A 5.3.1 bugfix release may be coming soon
   

   - See the confusion matrix
    for a classifier

   - Remove a nasty classloader hack that broke MorfologikFilter
   , and fix it correctly
    so you can pass the
   dictionary as a URI

   - The new BoostQuery decouples Query from boosting
   , but it was missing
   its rewrite method 

   - How can we compress postings payloads
   ?

   - Nested conjunctions should always be flattened
   

   - MultiCollector did not handle early termination properly
   

   - Add a point-within-distance query
    implemented with BKD
   trees

   - Speed up IndexSearcher.count
   when a query is so
   simple (match all, single term) that we can use index statistics instead

   - The integration of BKDTree and Geo3D
   is done (for Lucene
   5.4.0), providing accurate and fast earth-surface "point in shape" queries,
   but we need to make its randomized tests more evil by simulating planets
   more squashed than earth
   , requiring somecrazy
   math
   
,
   including Lagrange multipliers
   

   - GeoPointDistanceQuery is buggy with large distances
   

   - Don't use approximations
    for MatchAllDocsQuery,
   and give it a dedicated BulkScorer
   

   - Dodge bugs in Java's collators
   

   - Windows NTFS pending delete state for a file
    causes assertion
   failures in Lucene; we should fix Lucene's WindowsFS to also simulate
   this state 

   - Symlinks to an index directory continue to cause problems for users
   

   - CheckIndex cannot handle corrupt .si
   files

   - Reduce heap used by 
CompressingStoredFieldsWriter when writing large strings during
   indexing

   - Reduce heap used by
 the
   new geo point queries by building the BytesRef on demand for sub-ranges

   - GeoPointDistanceRangeQuery will match points within a min/max distance
   range 

   - When you incorrectly index nested documents the resulting error
   messages are very confusing
   

   - DisjunctionMaxQuery, BoostingQuery and BoostedQuery now use
   IndexSearcher to create sub-weights
    so caching can apply

Mike McCandless

[jira] [Commented] (LUCENE-6776) Randomized planet model shows up additional XYZBounds errors

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6776:


bq. Unfortunately I can't reproduce any of the failures that beasting finds!! 
If there's any way to fix this I'd greatly appreciate it...

Hmm that's very bad.

Maybe try dropping {{numThreads}} to 1 (and put a nocommit comment) and find a 
failing seed and then see if that fixes the "unable to repro"?

What exact command line are you using for beasting?  Maybe there is a bug in 
the "Reproduce with: XXX" logic.

> Randomized planet model shows up additional XYZBounds errors
> 
>
> Key: LUCENE-6776
> URL: https://issues.apache.org/jira/browse/LUCENE-6776
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Karl Wright
> Attachments: LUCENE-6776.patch, LUCENE-6776.patch
>
>
> Adding randomized PlanetModel construction causes points to be generated 
> inside a shape that are outside XYZBounds.  [~mikemccand] please take note.



--
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-8010) Allow WordBreakSolrSpellChecker to break when one word matches

[Joshua Edwards (JIRA)]

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

Joshua Edwards updated SOLR-8010:
-
Attachment: WordBreakDontRequireWordOnBothSides.patch

Including a patch that was written against 4.10.X that allows this to be 
enabled via configuration.

> Allow WordBreakSolrSpellChecker to break when one word matches
> --
>
> Key: SOLR-8010
> URL: https://issues.apache.org/jira/browse/SOLR-8010
> Project: Solr
>  Issue Type: Improvement
>  Components: spellchecker
>Affects Versions: 4.10.4, 5.3
>Reporter: Joshua Edwards
> Attachments: WordBreakDontRequireWordOnBothSides.patch
>
>
> The WordBreakSolrSpellChecker only works if both words that are being broken 
> are in the dictionary.  This prevents the spell checker from breaking in 
> other valid use cases - such as when one of the words has a synonym that is 
> in the dictionary, or when one of the words is misspelled.  I would like to 
> enable (via configuration) the option to break when one of the two words is 
> in the dictionary, but the other is not.  



--
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-8010) Allow WordBreakSolrSpellChecker to break when one word matches

[Joshua Edwards (JIRA)]

Joshua Edwards created SOLR-8010:


 Summary: Allow WordBreakSolrSpellChecker to break when one word 
matches
 Key: SOLR-8010
 URL: https://issues.apache.org/jira/browse/SOLR-8010
 Project: Solr
  Issue Type: Improvement
  Components: spellchecker
Affects Versions: 5.3, 4.10.4
Reporter: Joshua Edwards


The WordBreakSolrSpellChecker only works if both words that are being broken 
are in the dictionary.  This prevents the spell checker from breaking in other 
valid use cases - such as when one of the words has a synonym that is in the 
dictionary, or when one of the words is misspelled.  I would like to enable 
(via configuration) the option to break when one of the two words is in the 
dictionary, but the other is not.  



--
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-6781) BoostingQuery should implement rewrite

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-6781: BoostingQuery implements rewrite().

> BoostingQuery should implement rewrite
> --
>
> Key: LUCENE-6781
> URL: https://issues.apache.org/jira/browse/LUCENE-6781
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6781.patch
>
>
> BoostingQuery does not rewrite so it may call createWeight on queries that 
> are not in their rewritten form.



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

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

[jira] [Resolved] (LUCENE-6781) BoostingQuery should implement rewrite

[Adrien Grand (JIRA)]

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

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

> BoostingQuery should implement rewrite
> --
>
> Key: LUCENE-6781
> URL: https://issues.apache.org/jira/browse/LUCENE-6781
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6781.patch
>
>
> BoostingQuery does not rewrite so it may call createWeight on queries that 
> are not in their rewritten form.



--
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-6781) BoostingQuery should implement rewrite

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-6781: BoostingQuery implements rewrite().

> BoostingQuery should implement rewrite
> --
>
> Key: LUCENE-6781
> URL: https://issues.apache.org/jira/browse/LUCENE-6781
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6781.patch
>
>
> BoostingQuery does not rewrite so it may call createWeight on queries that 
> are not in their rewritten form.



--
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-6776) Randomized planet model shows up additional XYZBounds errors

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-6776:
-

[~mikemccand]: It appears that GeoPath's occasionally have some trouble when 
the planet model gets more extreme than WGS84.  It will take some research to 
get to the bottom of that. Unfortunately I can't reproduce any of the failures 
that beasting finds!!  If there's any way to fix this I'd greatly appreciate 
it...

> Randomized planet model shows up additional XYZBounds errors
> 
>
> Key: LUCENE-6776
> URL: https://issues.apache.org/jira/browse/LUCENE-6776
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Karl Wright
> Attachments: LUCENE-6776.patch, LUCENE-6776.patch
>
>
> Adding randomized PlanetModel construction causes points to be generated 
> inside a shape that are outside XYZBounds.  [~mikemccand] please take note.



--
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-6779) Reduce memory allocated by CompressingStoredFieldsWriter to write large strings

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on LUCENE-6779:
---

Thanks [~rcmuir]. I like this idea of writing directly to the byte array of 
GrowableByteArrayDataOutput and doing away with the intermediate buffer 
entirely.

I'll benchmark this method and report what I find.

> Reduce memory allocated by CompressingStoredFieldsWriter to write large 
> strings
> ---
>
> Key: LUCENE-6779
> URL: https://issues.apache.org/jira/browse/LUCENE-6779
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/codecs
>Reporter: Shalin Shekhar Mangar
> Attachments: LUCENE-6779.patch, LUCENE-6779_alt.patch
>
>
> In SOLR-7927, I am trying to reduce the memory required to index very large 
> documents (between 10 to 100MB) and one of the places which allocate a lot of 
> heap is the UTF8 encoding in CompressingStoredFieldsWriter. The same problem 
> existed in JavaBinCodec and we reduced its memory allocation by falling back 
> to a double pass approach in SOLR-7971 when the utf8 size of the string is 
> greater than 64KB.
> I propose to make the same changes to CompressingStoredFieldsWriter as we 
> made to JavaBinCodec in SOLR-7971.



--
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-6776) Randomized planet model shows up additional XYZBounds errors

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-6776:

Attachment: LUCENE-6776.patch

[~mikemccand] This patch calculates x and y bounds using lagrange multipliers.  
It seems to generally work, but it failed a beasting run.  Unfortunately, the 
failure did not reproduce, so not quite sure what happened there.  Am trying to 
get a reproducible failure.


> Randomized planet model shows up additional XYZBounds errors
> 
>
> Key: LUCENE-6776
> URL: https://issues.apache.org/jira/browse/LUCENE-6776
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Karl Wright
> Attachments: LUCENE-6776.patch, LUCENE-6776.patch
>
>
> Adding randomized PlanetModel construction causes points to be generated 
> inside a shape that are outside XYZBounds.  [~mikemccand] please take note.



--
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-6781) BoostingQuery should implement rewrite

[Adrien Grand (JIRA)]

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

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

Patch.

> BoostingQuery should implement rewrite
> --
>
> Key: LUCENE-6781
> URL: https://issues.apache.org/jira/browse/LUCENE-6781
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6781.patch
>
>
> BoostingQuery does not rewrite so it may call createWeight on queries that 
> are not in their rewritten form.



--
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-6781) BoostingQuery should implement rewrite

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-6781:


 Summary: BoostingQuery should implement rewrite
 Key: LUCENE-6781
 URL: https://issues.apache.org/jira/browse/LUCENE-6781
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor


BoostingQuery does not rewrite so it may call createWeight on queries that are 
not in their rewritten form.



--
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-6772) MultiCollector should catch CollectionTerminatedException

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-6772: MultiCollector now handles CollectionTerminatedException.

> MultiCollector should catch CollectionTerminatedException
> -
>
> Key: LUCENE-6772
> URL: https://issues.apache.org/jira/browse/LUCENE-6772
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6772.patch
>
>
> If you wrap two collectors in a MultiCollector and one of them terminates 
> early, then it will also make the other one terminate since MultiCollector 
> propagates the CollectionTerminatedException.



--
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-6772) MultiCollector should catch CollectionTerminatedException

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-6772: MultiCollector now handles CollectionTerminatedException.

> MultiCollector should catch CollectionTerminatedException
> -
>
> Key: LUCENE-6772
> URL: https://issues.apache.org/jira/browse/LUCENE-6772
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6772.patch
>
>
> If you wrap two collectors in a MultiCollector and one of them terminates 
> early, then it will also make the other one terminate since MultiCollector 
> propagates the CollectionTerminatedException.



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

5.3.1 bug fix release

[Noble Paul]

There are a couple of bugs fixed in 5.3 release. Should we go ahead
with a bug fix release .


-- 
-
Noble Paul

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

[jira] [Commented] (LUCENE-6776) Randomized planet model shows up additional XYZBounds errors

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-6776:
-

After fixing one problem with the above math, I got the x bounds working well.  
Then I implemented y bounds, but unfortunately that code fails an assertion.  X 
and Y are perfectly symmetric with one another so I was able to verify the math 
exactly, so the problem must be implementation related.  Still digging...

> Randomized planet model shows up additional XYZBounds errors
> 
>
> Key: LUCENE-6776
> URL: https://issues.apache.org/jira/browse/LUCENE-6776
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Karl Wright
> Attachments: LUCENE-6776.patch
>
>
> Adding randomized PlanetModel construction causes points to be generated 
> inside a shape that are outside XYZBounds.  [~mikemccand] please take note.



--
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-MAVEN] Lucene-Solr-Maven-trunk #1532: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1532/

No tests ran.

Build Log:
[...truncated 26222 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/build.xml:791: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/build.xml:290: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/lucene/build.xml:416:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/lucene/common-build.xml:2162:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/lucene/common-build.xml:1656:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/lucene/common-build.xml:574:
 Error deploying artifact 'org.apache.lucene:lucene-queryparser:jar': Error 
installing artifact's metadata: Error while deploying metadata: Failed to 
transfer file: 
https://repository.apache.org/content/repositories/snapshots/org/apache/lucene/lucene-queryparser/6.0.0-SNAPSHOT/maven-metadata.xml.
 Return code is: 502

Total time: 15 minutes 57 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Commented] (LUCENE-6779) Reduce memory allocated by CompressingStoredFieldsWriter to write large strings

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-6779:
-

I like what Robert suggested. I'd still use Character constants/ methods where 
applicable though. Not that I don't know what the code means, but for somebody 
not familiar with UTF8 it may be easier on the eyes.

> Reduce memory allocated by CompressingStoredFieldsWriter to write large 
> strings
> ---
>
> Key: LUCENE-6779
> URL: https://issues.apache.org/jira/browse/LUCENE-6779
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/codecs
>Reporter: Shalin Shekhar Mangar
> Attachments: LUCENE-6779.patch, LUCENE-6779_alt.patch
>
>
> In SOLR-7927, I am trying to reduce the memory required to index very large 
> documents (between 10 to 100MB) and one of the places which allocate a lot of 
> heap is the UTF8 encoding in CompressingStoredFieldsWriter. The same problem 
> existed in JavaBinCodec and we reduced its memory allocation by falling back 
> to a double pass approach in SOLR-7971 when the utf8 size of the string is 
> greater than 64KB.
> I propose to make the same changes to CompressingStoredFieldsWriter as we 
> made to JavaBinCodec in SOLR-7971.



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