[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 1830 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1830/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 6 tests failed. REGRESSION: org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.testDistribSearch Error Message: No live SolrServers available to handle this request:[https://127.0.0.1:50020, https://127.0.0.1:50017, https://127.0.0.1:50012] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[https://127.0.0.1:50020, https://127.0.0.1:50017, https://127.0.0.1:50012] at __randomizedtesting.SeedInfo.seed([6C0A7B87488AFFA4:EDECF59F3FD59F98]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:322) at org.apache.solr.client.solrj.impl.CloudSolrServer.sendRequest(CloudSolrServer.java:874) at org.apache.solr.client.solrj.impl.CloudSolrServer.requestWithRetryOnStaleState(CloudSolrServer.java:658) at org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:601) at org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.removeAndWaitForLastReplicaGone(DeleteLastCustomShardedReplicaTest.java:116) at org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.doTest(DeleteLastCustomShardedReplicaTest.java:106) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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.jav
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_20) - Build # 11242 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11242/ Java: 64bit/jdk1.8.0_20 -XX:-UseCompressedOops -XX:+UseParallelGC 5 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestZkChroot Error Message: Resource in scope SUITE failed to close. Resource was registered from thread Thread[id=5391, name=coreLoadExecutor-2759-thread-1, state=RUNNABLE, group=TGRP-TestZkChroot], registration stack trace below. Stack Trace: com.carrotsearch.randomizedtesting.ResourceDisposalError: Resource in scope SUITE failed to close. Resource was registered from thread Thread[id=5391, name=coreLoadExecutor-2759-thread-1, state=RUNNABLE, group=TGRP-TestZkChroot], registration stack trace below. at java.lang.Thread.getStackTrace(Thread.java:1552) at com.carrotsearch.randomizedtesting.RandomizedContext.closeAtEnd(RandomizedContext.java:166) at org.apache.lucene.util.LuceneTestCase.closeAfterSuite(LuceneTestCase.java:731) at org.apache.lucene.util.LuceneTestCase.wrapDirectory(LuceneTestCase.java:1274) at org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1165) at org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1157) at org.apache.solr.core.MockDirectoryFactory.create(MockDirectoryFactory.java:40) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:351) at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:276) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:488) at org.apache.solr.core.SolrCore.(SolrCore.java:794) at org.apache.solr.core.SolrCore.(SolrCore.java:652) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:491) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.AssertionError: Directory not closed: MockDirectoryWrapper(RAMDirectory@6ef4213a lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@39743af1) at org.junit.Assert.fail(Assert.java:93) at org.apache.lucene.util.CloseableDirectory.close(CloseableDirectory.java:47) at com.carrotsearch.randomizedtesting.RandomizedRunner$2$1.apply(RandomizedRunner.java:699) at com.carrotsearch.randomizedtesting.RandomizedRunner$2$1.apply(RandomizedRunner.java:696) at com.carrotsearch.randomizedtesting.RandomizedContext.closeResources(RandomizedContext.java:183) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.afterAlways(RandomizedRunner.java:712) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) ... 1 more FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestZkChroot Error Message: Resource in scope SUITE failed to close. Resource was registered from thread Thread[id=5420, name=coreLoadExecutor-2769-thread-1, state=RUNNABLE, group=TGRP-TestZkChroot], registration stack trace below. Stack Trace: com.carrotsearch.randomizedtesting.ResourceDisposalError: Resource in scope SUITE failed to close. Resource was registered from thread Thread[id=5420, name=coreLoadExecutor-2769-thread-1, state=RUNNABLE, group=TGRP-TestZkChroot], registration stack trace below. at java.lang.Thread.getStackTrace(Thread.java:1552) at com.carrotsearch.randomizedtesting.RandomizedContext.closeAtEnd(RandomizedContext.java:166) at org.apache.lucene.util.LuceneTestCase.closeAfterSuite(LuceneTestCase.java:731) at org.apache.lucene.util.LuceneTestCase.wrapDirectory(LuceneTestCase.java:1274) at org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1165) at org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1157) at org.apache.solr.core.MockDirectoryFactory.create(MockDirectoryFactory.java:40) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:351) at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:276) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:488) at org.apache.solr.core.SolrCore.(SolrCore.java:794) at org.apache.solr.core.SolrCore.(SolrCore.java:652) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:491) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249) at java.util.co
[JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4849 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4849/ 7 tests failed. REGRESSION: org.apache.solr.cloud.DeleteReplicaTest.testDistribSearch Error Message: No live SolrServers available to handle this request:[https://127.0.0.1:31541/ln/ky, https://127.0.0.1:31530/ln/ky, https://127.0.0.1:31511/ln/ky, https://127.0.0.1:31538/ln/ky, https://127.0.0.1:31519/ln/ky] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[https://127.0.0.1:31541/ln/ky, https://127.0.0.1:31530/ln/ky, https://127.0.0.1:31511/ln/ky, https://127.0.0.1:31538/ln/ky, https://127.0.0.1:31519/ln/ky] at __randomizedtesting.SeedInfo.seed([293DA6A76D018679:A8DB28BF1A5EE645]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:322) at org.apache.solr.client.solrj.impl.CloudSolrServer.sendRequest(CloudSolrServer.java:874) at org.apache.solr.client.solrj.impl.CloudSolrServer.requestWithRetryOnStaleState(CloudSolrServer.java:658) at org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:601) at org.apache.solr.cloud.DeleteReplicaTest.removeAndWaitForReplicaGone(DeleteReplicaTest.java:139) at org.apache.solr.cloud.DeleteReplicaTest.deleteLiveReplicaTest(DeleteReplicaTest.java:123) at org.apache.solr.cloud.DeleteReplicaTest.doTest(DeleteReplicaTest.java:87) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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(StatementAdapte
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_67) - Build # 11241 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11241/ Java: 64bit/jdk1.7.0_67 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 5 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestZkChroot Error Message: Resource in scope SUITE failed to close. Resource was registered from thread Thread[id=4566, name=coreLoadExecutor-2685-thread-1, state=RUNNABLE, group=TGRP-TestZkChroot], registration stack trace below. Stack Trace: com.carrotsearch.randomizedtesting.ResourceDisposalError: Resource in scope SUITE failed to close. Resource was registered from thread Thread[id=4566, name=coreLoadExecutor-2685-thread-1, state=RUNNABLE, group=TGRP-TestZkChroot], registration stack trace below. at java.lang.Thread.getStackTrace(Thread.java:1589) at com.carrotsearch.randomizedtesting.RandomizedContext.closeAtEnd(RandomizedContext.java:166) at org.apache.lucene.util.LuceneTestCase.closeAfterSuite(LuceneTestCase.java:731) at org.apache.lucene.util.LuceneTestCase.wrapDirectory(LuceneTestCase.java:1274) at org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1165) at org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1157) at org.apache.solr.core.MockDirectoryFactory.create(MockDirectoryFactory.java:40) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:351) at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:276) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:488) at org.apache.solr.core.SolrCore.(SolrCore.java:794) at org.apache.solr.core.SolrCore.(SolrCore.java:652) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:491) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.AssertionError: Directory not closed: MockDirectoryWrapper(RAMDirectory@7241e48d lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@2e0eca1b) at org.junit.Assert.fail(Assert.java:93) at org.apache.lucene.util.CloseableDirectory.close(CloseableDirectory.java:47) at com.carrotsearch.randomizedtesting.RandomizedRunner$2$1.apply(RandomizedRunner.java:699) at com.carrotsearch.randomizedtesting.RandomizedRunner$2$1.apply(RandomizedRunner.java:696) at com.carrotsearch.randomizedtesting.RandomizedContext.closeResources(RandomizedContext.java:183) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.afterAlways(RandomizedRunner.java:712) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) ... 1 more FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestZkChroot Error Message: Resource in scope SUITE failed to close. Resource was registered from thread Thread[id=4586, name=coreLoadExecutor-2692-thread-1, state=RUNNABLE, group=TGRP-TestZkChroot], registration stack trace below. Stack Trace: com.carrotsearch.randomizedtesting.ResourceDisposalError: Resource in scope SUITE failed to close. Resource was registered from thread Thread[id=4586, name=coreLoadExecutor-2692-thread-1, state=RUNNABLE, group=TGRP-TestZkChroot], registration stack trace below. at java.lang.Thread.getStackTrace(Thread.java:1589) at com.carrotsearch.randomizedtesting.RandomizedContext.closeAtEnd(RandomizedContext.java:166) at org.apache.lucene.util.LuceneTestCase.closeAfterSuite(LuceneTestCase.java:731) at org.apache.lucene.util.LuceneTestCase.wrapDirectory(LuceneTestCase.java:1274) at org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1165) at org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1157) at org.apache.solr.core.MockDirectoryFactory.create(MockDirectoryFactory.java:40) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:351) at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:276) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:488) at org.apache.solr.core.SolrCore.(SolrCore.java:794) at org.apache.solr.core.SolrCore.(SolrCore.java:652) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:491) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249) at java.ut
[jira] [Commented] (LUCENE-5945) Full cutover to Path api from java.io.File
[ https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133055#comment-14133055 ] ASF subversion and git services commented on LUCENE-5945: - Commit 1624800 from [~rcmuir] in branch 'dev/trunk' [ https://svn.apache.org/r1624800 ] LUCENE-5945: more test cleanups > Full cutover to Path api from java.io.File > -- > > Key: LUCENE-5945 > URL: https://issues.apache.org/jira/browse/LUCENE-5945 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Fix For: 5.0 > > Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch > > > Using NIO2 has a lot of benefits: > * more fine grained exception handling > * clearer semantics about what happens > * additional functionality > * possibility to work with virtual filesystems, etc. > We already banned File.delete and switched to Files.delete, I think we should > ban File completely (except for some sugar methods that just forward with > .toPath, like FSDirectory.open) > For tests, ideally we go a little further and ban methods like > FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure > all Paths are created via one protected method. This leaves open the > possibility to mock up filesystem behavior at a lower level in tests in the > future. -- 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: svn commit: r1624773 - in /lucene/dev/branches/branch_4x: ./ lucene/ lucene/core/ lucene/core/src/java/org/apache/lucene/codecs/lucene46/Lucene46SegmentInfoWriter.java
How would the Version be constructed with an invalid major version, given
this exact check in the constructor (and the fact that the only way to
construct is through Version.parse)?
On Sat, Sep 13, 2014 at 11:48 AM, wrote:
> Author: mikemccand
> Date: Sat Sep 13 18:48:41 2014
> New Revision: 1624773
>
> URL: http://svn.apache.org/r1624773
> Log:
> detect invalid major version when writing .si
>
> Modified:
> lucene/dev/branches/branch_4x/ (props changed)
> lucene/dev/branches/branch_4x/lucene/ (props changed)
> lucene/dev/branches/branch_4x/lucene/core/ (props changed)
>
> lucene/dev/branches/branch_4x/lucene/core/src/java/org/apache/lucene/codecs/lucene46/Lucene46SegmentInfoWriter.java
>
> Modified:
> lucene/dev/branches/branch_4x/lucene/core/src/java/org/apache/lucene/codecs/lucene46/Lucene46SegmentInfoWriter.java
> URL:
> http://svn.apache.org/viewvc/lucene/dev/branches/branch_4x/lucene/core/src/java/org/apache/lucene/codecs/lucene46/Lucene46SegmentInfoWriter.java?rev=1624773&r1=1624772&r2=1624773&view=diff
>
> ==
> ---
> lucene/dev/branches/branch_4x/lucene/core/src/java/org/apache/lucene/codecs/lucene46/Lucene46SegmentInfoWriter.java
> (original)
> +++
> lucene/dev/branches/branch_4x/lucene/core/src/java/org/apache/lucene/codecs/lucene46/Lucene46SegmentInfoWriter.java
> Sat Sep 13 18:48:41 2014
> @@ -28,6 +28,7 @@ import org.apache.lucene.store.Directory
> import org.apache.lucene.store.IOContext;
> import org.apache.lucene.store.IndexOutput;
> import org.apache.lucene.util.IOUtils;
> +import org.apache.lucene.util.Version;
>
> /**
> * Lucene 4.0 implementation of {@link SegmentInfoWriter}.
> @@ -52,8 +53,12 @@ public class Lucene46SegmentInfoWriter e
> boolean success = false;
> try {
>CodecUtil.writeHeader(output, Lucene46SegmentInfoFormat.CODEC_NAME,
> Lucene46SegmentInfoFormat.VERSION_CURRENT);
> + Version version = si.getVersion();
> + if (version.major < 3 || version.major > 4) {
> +throw new IllegalArgumentException("invalid major version: should
> be 3 or 4 but got: " + version.major + " segment=" + si);
> + }
>// Write the Lucene version that created this segment, since 3.1
> - output.writeString(si.getVersion().toString());
> + output.writeString(version.toString());
>output.writeInt(si.getDocCount());
>
>output.writeByte((byte) (si.getUseCompoundFile() ? SegmentInfo.YES
> : SegmentInfo.NO));
>
>
>
[jira] [Updated] (LUCENE-5946) Change SimpleFSDirectory to use newByteChannel
[ https://issues.apache.org/jira/browse/LUCENE-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5946: Attachment: LUCENE-5946.patch Here's a patch with Uwe's approach. I put the current RandomAccessFile one in misc/ as RAFDirectory and cutover SimpleFSDirectory. all tests pass. > Change SimpleFSDirectory to use newByteChannel > -- > > Key: LUCENE-5946 > URL: https://issues.apache.org/jira/browse/LUCENE-5946 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-5946.patch > > > Currently our javadocs point to using SimpleFSDirectory "to avoid > ClosedByInterruptException". > But this is really bogus. If you interrupt() a thread doing i/o, then you > need to be prepared for the consequences. Its just that RAF is broken and not > interruptible at all, but that shouldnt justify us continuing to use it. > SimpleFSDirectory should be "the most portable", so it should use > Files.newByteChannel. And we should remove the javadocs/warnings about > ClosedByInterrupt -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_67) - Build # 4310 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4310/
Java: 64bit/jdk1.7.0_67 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC
1 tests failed.
FAILED:
junit.framework.TestSuite.org.apache.lucene.benchmark.byTask.TestPerfTasksParse
Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\benchmark\test\J0\temp\lucene.benchmark.byTask.TestPerfTasksParse-2D34950549928D3F-001\linefile-001.txt:
java.nio.file.AccessDeniedException:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\benchmark\test\J0\temp\lucene.benchmark.byTask.TestPerfTasksParse-2D34950549928D3F-001\linefile-001.txt
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\benchmark\test\J0\temp\lucene.benchmark.byTask.TestPerfTasksParse-2D34950549928D3F-001\linefile-002.txt:
java.nio.file.AccessDeniedException:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\benchmark\test\J0\temp\lucene.benchmark.byTask.TestPerfTasksParse-2D34950549928D3F-001\linefile-002.txt
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\benchmark\test\J0\temp\lucene.benchmark.byTask.TestPerfTasksParse-2D34950549928D3F-001:
java.nio.file.DirectoryNotEmptyException:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\benchmark\test\J0\temp\lucene.benchmark.byTask.TestPerfTasksParse-2D34950549928D3F-001
Stack Trace:
java.io.IOException: Could not remove the following files (in the order of
attempts):
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\benchmark\test\J0\temp\lucene.benchmark.byTask.TestPerfTasksParse-2D34950549928D3F-001\linefile-001.txt:
java.nio.file.AccessDeniedException:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\benchmark\test\J0\temp\lucene.benchmark.byTask.TestPerfTasksParse-2D34950549928D3F-001\linefile-001.txt
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\benchmark\test\J0\temp\lucene.benchmark.byTask.TestPerfTasksParse-2D34950549928D3F-001\linefile-002.txt:
java.nio.file.AccessDeniedException:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\benchmark\test\J0\temp\lucene.benchmark.byTask.TestPerfTasksParse-2D34950549928D3F-001\linefile-002.txt
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\benchmark\test\J0\temp\lucene.benchmark.byTask.TestPerfTasksParse-2D34950549928D3F-001:
java.nio.file.DirectoryNotEmptyException:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\benchmark\test\J0\temp\lucene.benchmark.byTask.TestPerfTasksParse-2D34950549928D3F-001
at __randomizedtesting.SeedInfo.seed([2D34950549928D3F]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:288)
at
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:126)
at
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
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 7622 lines...]
[junit4] Suite: org.apache.lucene.benchmark.byTask.TestPerfTasksParse
[junit4] 1> > queries:
[junit4] 1>
[junit4] 1> > queries:
[junit4] 1>
[junit4] 1> > queries:
[junit4] 1>
[junit4] 1> > queries:
[junit4] 1>
[junit4] 1> > queries:
[junit4] 1>
[junit4] 1> > queries:
[junit4] 1>
[junit4] 1> > queries:
[junit4] 1>
[junit4] 1> > queries:
[junit4] 1>
[junit4] 1> > queries:
[junit4] 1>
[junit4] 1> > queries:
[junit4] 1>
[junit4] 1> > queries:
[junit4] 1>
[junit4] 1> > queries:
[junit4] 1>
[junit4] 1> > queries:
[junit4] 1>
[junit4] 1> Spatial Strategy:
RecursivePrefixTreeStrategy(SPG:(QuadPrefixTree(maxLevels:26,ctx:SpatialContext{geo=true,
ca
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_40-ea-b04) - Build # 11240 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11240/ Java: 64bit/jdk1.8.0_40-ea-b04 -XX:+UseCompressedOops -XX:+UseG1GC 7 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestZkChroot Error Message: Resource in scope SUITE failed to close. Resource was registered from thread Thread[id=5251, name=coreLoadExecutor-2568-thread-1, state=RUNNABLE, group=TGRP-TestZkChroot], registration stack trace below. Stack Trace: com.carrotsearch.randomizedtesting.ResourceDisposalError: Resource in scope SUITE failed to close. Resource was registered from thread Thread[id=5251, name=coreLoadExecutor-2568-thread-1, state=RUNNABLE, group=TGRP-TestZkChroot], registration stack trace below. at java.lang.Thread.getStackTrace(Thread.java:1552) at com.carrotsearch.randomizedtesting.RandomizedContext.closeAtEnd(RandomizedContext.java:166) at org.apache.lucene.util.LuceneTestCase.closeAfterSuite(LuceneTestCase.java:729) at org.apache.lucene.util.LuceneTestCase.wrapDirectory(LuceneTestCase.java:1272) at org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1163) at org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1155) at org.apache.solr.core.MockDirectoryFactory.create(MockDirectoryFactory.java:40) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:351) at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:276) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:488) at org.apache.solr.core.SolrCore.(SolrCore.java:794) at org.apache.solr.core.SolrCore.(SolrCore.java:652) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:491) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.AssertionError: Directory not closed: MockDirectoryWrapper(RAMDirectory@3373529f lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@48072962) at org.junit.Assert.fail(Assert.java:93) at org.apache.lucene.util.CloseableDirectory.close(CloseableDirectory.java:47) at com.carrotsearch.randomizedtesting.RandomizedRunner$2$1.apply(RandomizedRunner.java:699) at com.carrotsearch.randomizedtesting.RandomizedRunner$2$1.apply(RandomizedRunner.java:696) at com.carrotsearch.randomizedtesting.RandomizedContext.closeResources(RandomizedContext.java:183) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.afterAlways(RandomizedRunner.java:712) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) ... 1 more FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestZkChroot Error Message: Resource in scope SUITE failed to close. Resource was registered from thread Thread[id=5276, name=coreLoadExecutor-2578-thread-1, state=RUNNABLE, group=TGRP-TestZkChroot], registration stack trace below. Stack Trace: com.carrotsearch.randomizedtesting.ResourceDisposalError: Resource in scope SUITE failed to close. Resource was registered from thread Thread[id=5276, name=coreLoadExecutor-2578-thread-1, state=RUNNABLE, group=TGRP-TestZkChroot], registration stack trace below. at java.lang.Thread.getStackTrace(Thread.java:1552) at com.carrotsearch.randomizedtesting.RandomizedContext.closeAtEnd(RandomizedContext.java:166) at org.apache.lucene.util.LuceneTestCase.closeAfterSuite(LuceneTestCase.java:729) at org.apache.lucene.util.LuceneTestCase.wrapDirectory(LuceneTestCase.java:1272) at org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1163) at org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1155) at org.apache.solr.core.MockDirectoryFactory.create(MockDirectoryFactory.java:40) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:351) at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:276) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:488) at org.apache.solr.core.SolrCore.(SolrCore.java:794) at org.apache.solr.core.SolrCore.(SolrCore.java:652) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:491) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249) at java.util.c
[jira] [Commented] (LUCENE-5945) Full cutover to Path api from java.io.File
[ https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133026#comment-14133026 ] ASF subversion and git services commented on LUCENE-5945: - Commit 1624791 from [~thetaphi] in branch 'dev/trunk' [ https://svn.apache.org/r1624791 ] LUCENE-5945: Cleanup & javadocs > Full cutover to Path api from java.io.File > -- > > Key: LUCENE-5945 > URL: https://issues.apache.org/jira/browse/LUCENE-5945 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Fix For: 5.0 > > Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch > > > Using NIO2 has a lot of benefits: > * more fine grained exception handling > * clearer semantics about what happens > * additional functionality > * possibility to work with virtual filesystems, etc. > We already banned File.delete and switched to Files.delete, I think we should > ban File completely (except for some sugar methods that just forward with > .toPath, like FSDirectory.open) > For tests, ideally we go a little further and ban methods like > FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure > all Paths are created via one protected method. This leaves open the > possibility to mock up filesystem behavior at a lower level in tests in the > future. -- 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-5945) Full cutover to Path api from java.io.File
[ https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133023#comment-14133023 ] ASF subversion and git services commented on LUCENE-5945: - Commit 1624790 from [~thetaphi] in branch 'dev/trunk' [ https://svn.apache.org/r1624790 ] LUCENE-5945: Nuke one more ZipFile usage > Full cutover to Path api from java.io.File > -- > > Key: LUCENE-5945 > URL: https://issues.apache.org/jira/browse/LUCENE-5945 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Fix For: 5.0 > > Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch > > > Using NIO2 has a lot of benefits: > * more fine grained exception handling > * clearer semantics about what happens > * additional functionality > * possibility to work with virtual filesystems, etc. > We already banned File.delete and switched to Files.delete, I think we should > ban File completely (except for some sugar methods that just forward with > .toPath, like FSDirectory.open) > For tests, ideally we go a little further and ban methods like > FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure > all Paths are created via one protected method. This leaves open the > possibility to mock up filesystem behavior at a lower level in tests in the > future. -- 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: [VOTE] Move trunk to Java 8
I hate to be on the side of either “I always know exactly what should happen, no one else does, I’ll do what I want anyway” or “trunk is just about cutting edge so obviously our java version should also be cutting edge”, because neither are very appealing to me. Sill, I’m +1 moving trunk to Java 8. - Mark http://about.me/markrmiller > On Sep 12, 2014, at 11:41 AM, Ryan Ernst wrote: > > It has been 6 months since Java 8 was released. It has proven to be > both stable (no issues like with the initial release of java 7) and > faster. And there are a ton of features that would make our lives as > developers easier (and that can improve the quality of Lucene 5 when > it is eventually released). > > We should stay ahead of the curve, and move trunk to Java 8. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
+1 This is trunk, it doesnt impact anyones users :) On Fri, Sep 12, 2014 at 11:41 AM, Ryan Ernst wrote: > It has been 6 months since Java 8 was released. It has proven to be > both stable (no issues like with the initial release of java 7) and > faster. And there are a ton of features that would make our lives as > developers easier (and that can improve the quality of Lucene 5 when > it is eventually released). > > We should stay ahead of the curve, and move trunk to Java 8. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6513) Add a collectionsAPI call ASSIGNPREFERREDLEADERS
[ https://issues.apache.org/jira/browse/SOLR-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133010#comment-14133010 ] Erick Erickson commented on SOLR-6513: -- It'd probably also be good to add something to the shard when getting the clusterstatus, something akin to: "preferredLeaders assigned/actual":"32/30" that would represent the congruence (or lack thereof) of the model and reality. > Add a collectionsAPI call ASSIGNPREFERREDLEADERS > > > Key: SOLR-6513 > URL: https://issues.apache.org/jira/browse/SOLR-6513 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson > > Another sub-task for SOLR-6491. The ability to assign a preferred leader on a > node-by-node basis is nice, but tedious to get right for a sysadmin, > especially if there are, say, 100s of nodes hosting a system. This JIRA would > essentially provide an automatic mechanism for assigning these roles (or > properties). This particular command would NOT re-elect leaders, just change > the flag in the clusterstate. > My idea for this version is fairly limited. You'd have to specify a > collection and there would be no attempt to, say, evenly distribute the > preferred leader role/property for this collection by looking at _other_ > collections. Or by looking at underlying hardware capabilities. Or > It would be a pretty simple round-robin assignment. About the only > intelligence built in would be to change as few roles/properties as possible. > Let's say that the correct number of nodes for this role turned out to be 3. > Any node currently having 3 preferred leaders for this collection would NOT > be changed. Any node having 2 preferred leaders would have one added that > would be taken from some node with > 3 preferred leaders. > This probably needs an optional parameter, something like > "includeInactiveNodes=true|false" -- 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-5946) Change SimpleFSDirectory to use newByteChannel
[ https://issues.apache.org/jira/browse/LUCENE-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133009#comment-14133009 ] Uwe Schindler commented on LUCENE-5946: --- One possibility would be to move the old SimpleFSDirectory to lucene/misc or lucene/snapshot, named RAFDirectory. SimpleFSDirectory in trunk should use Java 7 APIs only. The interrupt() arguments were never seen in any issue report, it was only Simon mentioning it on an issue. Just dont use Future.cancel(true): [http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html#cancel(boolean)] It's your own fault if you do this with Lucene code. > Change SimpleFSDirectory to use newByteChannel > -- > > Key: LUCENE-5946 > URL: https://issues.apache.org/jira/browse/LUCENE-5946 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > > Currently our javadocs point to using SimpleFSDirectory "to avoid > ClosedByInterruptException". > But this is really bogus. If you interrupt() a thread doing i/o, then you > need to be prepared for the consequences. Its just that RAF is broken and not > interruptible at all, but that shouldnt justify us continuing to use it. > SimpleFSDirectory should be "the most portable", so it should use > Files.newByteChannel. And we should remove the javadocs/warnings about > ClosedByInterrupt -- 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: [VOTE] Move trunk to Java 8
On Sat, Sep 13, 2014 at 2:26 AM, Robert Muir wrote: > On Sat, Sep 13, 2014 at 1:46 AM, Erick Erickson > wrote: > >> The point remains that the end user users who are _not_ developers >> of Lucene/Solr are our "customers". Otherwise we're all just playing >> with ourselves. > > Not true. Lucene is a library. 100% of its users are developers. This is the Lucene/Solr project, not just Lucene. This also affects every other project (open source and commercial) that has Lucene or Solr as a dependency. -Yonik http://heliosearch.org - native code faceting, facet functions, sub-facets, off-heap data - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5946) Change SimpleFSDirectory to use newByteChannel
Robert Muir created LUCENE-5946: --- Summary: Change SimpleFSDirectory to use newByteChannel Key: LUCENE-5946 URL: https://issues.apache.org/jira/browse/LUCENE-5946 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Currently our javadocs point to using SimpleFSDirectory "to avoid ClosedByInterruptException". But this is really bogus. If you interrupt() a thread doing i/o, then you need to be prepared for the consequences. Its just that RAF is broken and not interruptible at all, but that shouldnt justify us continuing to use it. SimpleFSDirectory should be "the most portable", so it should use Files.newByteChannel. And we should remove the javadocs/warnings about ClosedByInterrupt -- 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: [VOTE] Move trunk to Java 8
bq: Not true. Lucene is a library. 100% of its users are developers. Well, developers don't operate in a vacuum either. There will be some set of them that cannot use Java 8. It's perfectly reasonable to decide that we can't confine ourselves forever because some people will be inconvenienced and go ahead with it. I'm not at all saying java8 is a bad idea here. I'm with Hoss though, unless and until there are better reasons given I'm -1 Erick On Sat, Sep 13, 2014 at 9:17 AM, Chris Hostetter wrote: > > : > : faster. And there are a ton of features that would make our lives as > : > : developers easier (and that can improve the quality of Lucene 5 when > : > : it is eventually released). > : > > : > Examples please? > > : The ability to specify default methods on interfaces. > > So far, that's the only concrete example of seen of the stated motivation > for this proposal. It doesn't strike me as a Game Changing langauge > feature worthy of making the jump -- Not stacked up against the concerns > expressed by several people about alienating existing users. > > I'm not opposed to moving to Java8, i'm just opposed to doing it w/o > more compelling reasons. > > -1 ... unless/until there are more examples of: a) how moving to > java 8 will make our lives easier; b) how java 8 will improve the quality > of Lucene. > > > > -Hoss > http://www.lucidworks.com/ > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6452) StatsComponent "missing" stat won't work with docValues=true and indexed=false
[ https://issues.apache.org/jira/browse/SOLR-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6452: --- Attachment: SOLR-6452-trunk.patch Added patch based on trunk. Added facet fields tests for integer and double types, and facet value stats is not available. Does it require new issue or reopen SOLR-6452? Implementation of this issue can be improved in few cases: 1. Accumulate methods should not return stats specific numbers (it is generic). Attached solution with container class. Also made them private scoped. Returning just missing fields from accumulate methods does not allow you to extend it with additional counts field, therefore i propose to leave void. 2. Reduced visibility of fields in FieldFacetStats. Created getter to expose FieldFacetStats.facetStatsValues. 3. Methods FieldFacetStats#accumulateMissing and FieldFacetStats#accumulateTermNum does not throw any IO exception 4. We don't need intermediate maps to accumulate missing counts. Changed org.apache.solr.handler.component.FieldFacetStats#facetMissingNum to work directly on StatsValues structure and removed org.apache.solr.handler.component.FieldFacetStats#accumulateMissing. We don't need to have it in 2 phases. > StatsComponent "missing" stat won't work with docValues=true and indexed=false > -- > > Key: SOLR-6452 > URL: https://issues.apache.org/jira/browse/SOLR-6452 > Project: Solr > Issue Type: Bug >Affects Versions: 4.10, 5.0 >Reporter: Tomás Fernández Löbbe >Assignee: Tomás Fernández Löbbe > Fix For: 4.11, 5.0 > > Attachments: SOLR-6452-trunk.patch, SOLR-6452-trunk.patch, > SOLR-6452-trunk.patch, SOLR-6452.patch, SOLR-6452.patch, SOLR-6452.patch > > > StatsComponent can work with DocValues, but it still required to use > indexed=true for the "missing" stat to work. Missing values should be > obtained from the docValues too. -- 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-5945) Full cutover to Path api from java.io.File
[ https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132985#comment-14132985 ] Uwe Schindler commented on LUCENE-5945: --- I committed the changes. Basically, the condition would not be needed at all, as Solr already overrides the base checks. But I left the condition in for the tools. > Full cutover to Path api from java.io.File > -- > > Key: LUCENE-5945 > URL: https://issues.apache.org/jira/browse/LUCENE-5945 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Fix For: 5.0 > > Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch > > > Using NIO2 has a lot of benefits: > * more fine grained exception handling > * clearer semantics about what happens > * additional functionality > * possibility to work with virtual filesystems, etc. > We already banned File.delete and switched to Files.delete, I think we should > ban File completely (except for some sugar methods that just forward with > .toPath, like FSDirectory.open) > For tests, ideally we go a little further and ban methods like > FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure > all Paths are created via one protected method. This leaves open the > possibility to mock up filesystem behavior at a lower level in tests in the > future. -- 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-5945) Full cutover to Path api from java.io.File
[ https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132984#comment-14132984 ] ASF subversion and git services commented on LUCENE-5945: - Commit 1624785 from [~thetaphi] in branch 'dev/trunk' [ https://svn.apache.org/r1624785 ] LUCENE-5945: Changes to forbidden, as discussed on issue. > Full cutover to Path api from java.io.File > -- > > Key: LUCENE-5945 > URL: https://issues.apache.org/jira/browse/LUCENE-5945 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Fix For: 5.0 > > Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch > > > Using NIO2 has a lot of benefits: > * more fine grained exception handling > * clearer semantics about what happens > * additional functionality > * possibility to work with virtual filesystems, etc. > We already banned File.delete and switched to Files.delete, I think we should > ban File completely (except for some sugar methods that just forward with > .toPath, like FSDirectory.open) > For tests, ideally we go a little further and ban methods like > FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure > all Paths are created via one protected method. This leaves open the > possibility to mock up filesystem behavior at a lower level in tests in the > future. -- 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-6517) CollectionsAPI call REELECTLEADERS
Erick Erickson created SOLR-6517: Summary: CollectionsAPI call REELECTLEADERS Key: SOLR-6517 URL: https://issues.apache.org/jira/browse/SOLR-6517 Project: Solr Issue Type: New Feature Affects Versions: 4.11, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Perhaps the final piece of SOLR-6491. Once the preferred leadership roles are assigned, there has to be a command "make it so Mr. Solr". This is something of a placeholder to collect ideas. One wouldn't want to flood the system with hundreds of re-assignments at once. Should this be synchronous or asnych? Should it make the best attempt but not worry about perfection? Should it??? a collection=name parameter would be required and it would re-elect all the leaders that were on the 'wrong' node I'm thinking an optionally allowing one to specify a shard in the case where you wanted to make a very specific change. Note that there's no need to specify a particular replica, since there should be only a single preferredLeader per slice. This command would do nothing to any slice that did not have a replica with a preferredLeader role. Likewise it would do nothing if the slice in question already had the leader role assigned to the node with the preferredLeader role. -- 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-5945) Full cutover to Path api from java.io.File
[ https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132977#comment-14132977 ] Uwe Schindler commented on LUCENE-5945: --- OK, will do this in a minute :-) > Full cutover to Path api from java.io.File > -- > > Key: LUCENE-5945 > URL: https://issues.apache.org/jira/browse/LUCENE-5945 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Fix For: 5.0 > > Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch > > > Using NIO2 has a lot of benefits: > * more fine grained exception handling > * clearer semantics about what happens > * additional functionality > * possibility to work with virtual filesystems, etc. > We already banned File.delete and switched to Files.delete, I think we should > ban File completely (except for some sugar methods that just forward with > .toPath, like FSDirectory.open) > For tests, ideally we go a little further and ban methods like > FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure > all Paths are created via one protected method. This leaves open the > possibility to mock up filesystem behavior at a lower level in tests in the > future. -- 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-5945) Full cutover to Path api from java.io.File
[ https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-5945. - Resolution: Fixed Fix Version/s: 5.0 I fixed as 5.0. If someone wants to backport, feel free. But I'm focusing on trunk. > Full cutover to Path api from java.io.File > -- > > Key: LUCENE-5945 > URL: https://issues.apache.org/jira/browse/LUCENE-5945 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Fix For: 5.0 > > Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch > > > Using NIO2 has a lot of benefits: > * more fine grained exception handling > * clearer semantics about what happens > * additional functionality > * possibility to work with virtual filesystems, etc. > We already banned File.delete and switched to Files.delete, I think we should > ban File completely (except for some sugar methods that just forward with > .toPath, like FSDirectory.open) > For tests, ideally we go a little further and ban methods like > FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure > all Paths are created via one protected method. This leaves open the > possibility to mock up filesystem behavior at a lower level in tests in the > future. -- 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-5945) Full cutover to Path api from java.io.File
[ https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132974#comment-14132974 ] Robert Muir commented on LUCENE-5945: - Uwe, please just commit it if it works. I dont understand it myself because my brain is damaged from fixing all file handling in benchmark/ > Full cutover to Path api from java.io.File > -- > > Key: LUCENE-5945 > URL: https://issues.apache.org/jira/browse/LUCENE-5945 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch > > > Using NIO2 has a lot of benefits: > * more fine grained exception handling > * clearer semantics about what happens > * additional functionality > * possibility to work with virtual filesystems, etc. > We already banned File.delete and switched to Files.delete, I think we should > ban File completely (except for some sugar methods that just forward with > .toPath, like FSDirectory.open) > For tests, ideally we go a little further and ban methods like > FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure > all Paths are created via one protected method. This leaves open the > possibility to mock up filesystem behavior at a lower level in tests in the > future. -- 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-5945) Full cutover to Path api from java.io.File
[
https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132972#comment-14132972
]
Uwe Schindler edited comment on LUCENE-5945 at 9/13/14 9:46 PM:
Basically, thats my change, which is trivial:
{code:xml}
{code}
was (Author: thetaphi):
Basically, thats my change, which is trivial:
{code:xml}
{code}
> Full cutover to Path api from java.io.File
> --
>
> Key: LUCENE-5945
> URL: https://issues.apache.org/jira/browse/LUCENE-5945
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
> Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch
>
>
> Using NIO2 has a lot of benefits:
> * more fine grained exception handling
> * clearer semantics about what happens
> * additional functionality
> * possibility to work with virtual filesystems, etc.
> We already banned File.delete and switched to Files.delete, I think we should
> ban File completely (except for some sugar methods that just forward with
> .toPath, like FSDirectory.open)
> For tests, ideally we go a little further and ban methods like
> FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure
> all Paths are created via one protected method. This leaves open the
> possibility to mock up filesystem behavior at a lower level in tests in the
> future.
--
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-5945) Full cutover to Path api from java.io.File
[ https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132973#comment-14132973 ] ASF subversion and git services commented on LUCENE-5945: - Commit 1624784 from [~rcmuir] in branch 'dev/trunk' [ https://svn.apache.org/r1624784 ] LUCENE-5945: Full cutover to Path api from java.io.File > Full cutover to Path api from java.io.File > -- > > Key: LUCENE-5945 > URL: https://issues.apache.org/jira/browse/LUCENE-5945 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch > > > Using NIO2 has a lot of benefits: > * more fine grained exception handling > * clearer semantics about what happens > * additional functionality > * possibility to work with virtual filesystems, etc. > We already banned File.delete and switched to Files.delete, I think we should > ban File completely (except for some sugar methods that just forward with > .toPath, like FSDirectory.open) > For tests, ideally we go a little further and ban methods like > FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure > all Paths are created via one protected method. This leaves open the > possibility to mock up filesystem behavior at a lower level in tests in the > future. -- 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-5945) Full cutover to Path api from java.io.File
[
https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132972#comment-14132972
]
Uwe Schindler edited comment on LUCENE-5945 at 9/13/14 9:45 PM:
Basically, thats my change, which is trivial:
{code:xml}
{code}
was (Author: thetaphi):
Basically, thats my change, which is trivial:
{code:xml}
{code}
> Full cutover to Path api from java.io.File
> --
>
> Key: LUCENE-5945
> URL: https://issues.apache.org/jira/browse/LUCENE-5945
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
> Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch
>
>
> Using NIO2 has a lot of benefits:
> * more fine grained exception handling
> * clearer semantics about what happens
> * additional functionality
> * possibility to work with virtual filesystems, etc.
> We already banned File.delete and switched to Files.delete, I think we should
> ban File completely (except for some sugar methods that just forward with
> .toPath, like FSDirectory.open)
> For tests, ideally we go a little further and ban methods like
> FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure
> all Paths are created via one protected method. This leaves open the
> possibility to mock up filesystem behavior at a lower level in tests in the
> future.
--
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-5945) Full cutover to Path api from java.io.File
[
https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132972#comment-14132972
]
Uwe Schindler edited comment on LUCENE-5945 at 9/13/14 9:45 PM:
Basically, thats my change, which is trivial:
{code:xml}
{code}
was (Author: thetaphi):
Basically, thats my change, which is trivial:
{code:xml}
{code}
> Full cutover to Path api from java.io.File
> --
>
> Key: LUCENE-5945
> URL: https://issues.apache.org/jira/browse/LUCENE-5945
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
> Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch
>
>
> Using NIO2 has a lot of benefits:
> * more fine grained exception handling
> * clearer semantics about what happens
> * additional functionality
> * possibility to work with virtual filesystems, etc.
> We already banned File.delete and switched to Files.delete, I think we should
> ban File completely (except for some sugar methods that just forward with
> .toPath, like FSDirectory.open)
> For tests, ideally we go a little further and ban methods like
> FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure
> all Paths are created via one protected method. This leaves open the
> possibility to mock up filesystem behavior at a lower level in tests in the
> future.
--
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-5945) Full cutover to Path api from java.io.File
[
https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132972#comment-14132972
]
Uwe Schindler commented on LUCENE-5945:
---
Basically, thats my change, which is trivial:
{code:xml}
{code}
> Full cutover to Path api from java.io.File
> --
>
> Key: LUCENE-5945
> URL: https://issues.apache.org/jira/browse/LUCENE-5945
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
> Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch
>
>
> Using NIO2 has a lot of benefits:
> * more fine grained exception handling
> * clearer semantics about what happens
> * additional functionality
> * possibility to work with virtual filesystems, etc.
> We already banned File.delete and switched to Files.delete, I think we should
> ban File completely (except for some sugar methods that just forward with
> .toPath, like FSDirectory.open)
> For tests, ideally we go a little further and ban methods like
> FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure
> all Paths are created via one protected method. This leaves open the
> possibility to mock up filesystem behavior at a lower level in tests in the
> future.
--
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-6512) Add a collections API call to attach arbitrary properties to a replica
[ https://issues.apache.org/jira/browse/SOLR-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-6512: - Description: This is a sub-task for SOLR-6491, but seems generally useful. Since this is in support of the "preferredLeader" functionality, I've run into some considerations that I wanted some feedback on how to handle. "preferredLeader" has the restriction that there should only be one per slice, so setting this for a particular node means removing the property for all the other replicas on the slice. Not a problem to do, my question is more whether this is something reasonable to enforce on an arbitrary property based on what that property is? Perfectly do-able, but "semantically challenged". Currently, this is never a node with "preferedLeader" set to "false", it is forcibly removed from other nodes in the slice when this property is assigned. The problem here is that there's nothing about assigning an arbitrary property to a node that would reasonably imply this kind of behavior. One could always control this with secondary flags on the command, e.g. "shardExclusive=true|false" for instance, perhaps with safety checks in for known one-per-shard properties like "preferredLeader". "preferredLeader" seems to fit more naturally into a "role", but currently ADDROLE and DELTEROLE have nothing to do with the notion of setting a role for a particular node relative to a collection/shard. Easy enough to add, but enforcing the "only one node per slice may have this role" rule there is similarly arbitrary and overloads the ADDROLE/DELETEROLE in a way that seems equally confusing. Plus, checking whether the required collection/shard/node params are present becomes based on the value of the property being set, which is all equally arbitrary. The other interesting thing is that setting an arbitrary property on a node would allow one to mess things up royally by, say, changing properties like "core", or "base_url" or node_name at will. Actually this is potentially useful, but very, very dangerous and I'm not particularly interested in supporting it ;). I suppose we could require a prefix, say the only settable properties are "property.whatever". We could also add something specific to nodes, something like ADDREPLICAROLE/DELETEREPLICAROLE, perhaps with sub-params like "onlyOneAllowedPerShard", but this gets messy and relies on the users "doing the right thing". I prefer enforcing rules like this based on the role I think. Or at least enforcing these kinds of requirements on the "preferredLeader" role if we go that way. What are people's thoughts here? I think I'm tending towards the ADDREPLICAROLE/DELETEREPLICAROLE way of doing this, but it's not set in stone. I have code locally for arbitrary properties that I can modify for the role bits. So, if I'm going to summarize the points I'd like feedback on: 1> Is setting arbitrary properties on a node desirable? If so, should we require a prefix like "property" to prevent resetting values SolrCloud depends on? 2> Is it better to piggyback on ADDROLE/DELETEROLE? Personally I'm not in favor of this one. Too messy with requiring additional parameters to work right in this case 3> Is the best option to create new collections API calls for ADDREPLICAROLE/DELETEREPLICAROLE that 3.1> require collection/slice/node parameters 3.2> enforces the "onlyOnePerShard" rule for certain known roles 3.3 v1> allows users to specify arbitrary roles something like "onlyOnePerShard" as an optional T|F parameter, otherwise is totally open. -or- 3.3 v2> No support other than "preferredLeader", only roles that are pre-defined are allowed, in which case the "onlyOnePerShard" is implicit in the role. was: This is a sub-task for SOLR-6491, but seems generally useful. Since this is in support of the "preferredLeader" functionality, I've run into some considerations that I wanted some feedback on how to handle. "preferredLeader" has the restriction that there should only be one per slice, so setting this for a particular node means removing the property for all the other replicas on the slice. Not a problem to do, my question is more whether this is something reasonable to enforce on an arbitrary property based on what that property is? Perfectly do-able, but "semantically challenged". Currently, this is never a node with "preferedLeader" set to "false", it is forcibly removed from other nodes in the slice when this property is assigned. The problem here is that there's nothing about assigning an arbitrary property to a node that would reasonably imply this kind of behavior. One could always control this with secondary flags on the command, e.g. "shardExclusive=true|false" for instance, perhaps with safety checks in for known one-per-shard properties like "preferredLeader". "preferredLeader" seems to fit more naturally into a "role"
[jira] [Commented] (LUCENE-5945) Full cutover to Path api from java.io.File
[ https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132969#comment-14132969 ] Uwe Schindler commented on LUCENE-5945: --- As I said, I will fix the forbidden. Just commit what you have, but don't complain about my changes, I will basically revert just the new target. We already need separate targets, because the base directories for tests and core are different. But we don't need a new target for additional signatures file with conditions. That's already built in. Please don't respond so aggressive, I have the right to make suggestions! And I want it correct! > Full cutover to Path api from java.io.File > -- > > Key: LUCENE-5945 > URL: https://issues.apache.org/jira/browse/LUCENE-5945 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch > > > Using NIO2 has a lot of benefits: > * more fine grained exception handling > * clearer semantics about what happens > * additional functionality > * possibility to work with virtual filesystems, etc. > We already banned File.delete and switched to Files.delete, I think we should > ban File completely (except for some sugar methods that just forward with > .toPath, like FSDirectory.open) > For tests, ideally we go a little further and ban methods like > FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure > all Paths are created via one protected method. This leaves open the > possibility to mock up filesystem behavior at a lower level in tests in the > future. -- 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-5945) Full cutover to Path api from java.io.File
[ https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132966#comment-14132966 ] Robert Muir commented on LUCENE-5945: - I did not refactor it Uwe. There were already 3 or 4 targets, one for each text file. I added one for my new text file. I can remove the forbidden apis part of this patch completely when committing. This patch was too much work and I do not care about optimizing 5 microseconds in the build. I care that things work and are correct. > Full cutover to Path api from java.io.File > -- > > Key: LUCENE-5945 > URL: https://issues.apache.org/jira/browse/LUCENE-5945 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch > > > Using NIO2 has a lot of benefits: > * more fine grained exception handling > * clearer semantics about what happens > * additional functionality > * possibility to work with virtual filesystems, etc. > We already banned File.delete and switched to Files.delete, I think we should > ban File completely (except for some sugar methods that just forward with > .toPath, like FSDirectory.open) > For tests, ideally we go a little further and ban methods like > FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure > all Paths are created via one protected method. This leaves open the > possibility to mock up filesystem behavior at a lower level in tests in the > future. -- 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-5945) Full cutover to Path api from java.io.File
[ https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132965#comment-14132965 ] Uwe Schindler commented on LUCENE-5945: --- bq. I will commit this patch and leave that to you. I don't want to refactor the current forbidden APIs logic in this issue. Its already a 500KB patch. You refactored it! I will fix it tomorrow once you committed (basically revert your additional target). So my suggestion is just to add the signatures file for lucene-only as a conditional to the original signatures fileset instead of adding a new target. > Full cutover to Path api from java.io.File > -- > > Key: LUCENE-5945 > URL: https://issues.apache.org/jira/browse/LUCENE-5945 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch > > > Using NIO2 has a lot of benefits: > * more fine grained exception handling > * clearer semantics about what happens > * additional functionality > * possibility to work with virtual filesystems, etc. > We already banned File.delete and switched to Files.delete, I think we should > ban File completely (except for some sugar methods that just forward with > .toPath, like FSDirectory.open) > For tests, ideally we go a little further and ban methods like > FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure > all Paths are created via one protected method. This leaves open the > possibility to mock up filesystem behavior at a lower level in tests in the > future. -- 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-5945) Full cutover to Path api from java.io.File
[
https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132961#comment-14132961
]
Robert Muir commented on LUCENE-5945:
-
{quote}
If you have quesions, I might take care tomorrow. I found out that if/unless
works with filesets include directive only a few days ago:
https://ant.apache.org/manual/Types/patternset.html
{quote}
I will commit this patch and leave that to you. I don't want to refactor the
current forbidden APIs logic in this issue. Its already a 500KB patch.
{quote}
One nit: in FilesystemResourceLoader.java
{quote}
Thank you Alan.
> Full cutover to Path api from java.io.File
> --
>
> Key: LUCENE-5945
> URL: https://issues.apache.org/jira/browse/LUCENE-5945
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
> Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch
>
>
> Using NIO2 has a lot of benefits:
> * more fine grained exception handling
> * clearer semantics about what happens
> * additional functionality
> * possibility to work with virtual filesystems, etc.
> We already banned File.delete and switched to Files.delete, I think we should
> ban File completely (except for some sugar methods that just forward with
> .toPath, like FSDirectory.open)
> For tests, ideally we go a little further and ban methods like
> FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure
> all Paths are created via one protected method. This leaves open the
> possibility to mock up filesystem behavior at a lower level in tests in the
> future.
--
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-6511) Fencepost error in LeaderInitiatedRecoveryThread
[
https://issues.apache.org/jira/browse/SOLR-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132960#comment-14132960
]
Alan Woodward commented on SOLR-6511:
-
I think you might have some extra stuff on the end of the patch?
Digging a bit further into the logs, maxTries is set to 1 because
ensureReplicaInLeaderInitiatedRecovery throws a SessionExpiredException
(presumably because ZK has noticed the network blip and removed the relevant
ephemeral node). Maybe maxTries should *always* be set to 120?
One thing that might be nice here would be to add a utility method to
ZkController called something like ensureLeadership(CloudDescriptor cd), which
checks if the core described by the CloudDescriptor really is the current
leader according to ZK, and throws an exception if it isn't.
> Fencepost error in LeaderInitiatedRecoveryThread
>
>
> Key: SOLR-6511
> URL: https://issues.apache.org/jira/browse/SOLR-6511
> Project: Solr
> Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Timothy Potter
> Attachments: SOLR-6511.patch
>
>
> At line 106:
> {code}
> while (continueTrying && ++tries < maxTries) {
> {code}
> should be
> {code}
> while (continueTrying && ++tries <= maxTries) {
> {code}
> This is only a problem when called from DistributedUpdateProcessor, as it can
> have maxTries set to 1, which means the loop is never actually run.
--
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-5945) Full cutover to Path api from java.io.File
[
https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132949#comment-14132949
]
Alan Woodward commented on LUCENE-5945:
---
This looks ace.
One nit: in FilesystemResourceLoader.java
{code}
throw new IllegalArgumentException("baseDirectory is not a directory")
{code}
should be
{code}
throw new IllegalArgumentException(baseDirectory + " is not a directory")
{code}
> Full cutover to Path api from java.io.File
> --
>
> Key: LUCENE-5945
> URL: https://issues.apache.org/jira/browse/LUCENE-5945
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
> Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch
>
>
> Using NIO2 has a lot of benefits:
> * more fine grained exception handling
> * clearer semantics about what happens
> * additional functionality
> * possibility to work with virtual filesystems, etc.
> We already banned File.delete and switched to Files.delete, I think we should
> ban File completely (except for some sugar methods that just forward with
> .toPath, like FSDirectory.open)
> For tests, ideally we go a little further and ban methods like
> FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure
> all Paths are created via one protected method. This leaves open the
> possibility to mock up filesystem behavior at a lower level in tests in the
> future.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 1829 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1829/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. REGRESSION: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.testDistribSearch Error Message: There were too many update fails - we expect it can happen, but shouldn't easily Stack Trace: java.lang.AssertionError: There were too many update fails - we expect it can happen, but shouldn't easily at __randomizedtesting.SeedInfo.seed([D791DF4A169F3D00:5677515261C05D3C]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.doTest(ChaosMonkeyNothingIsSafeTest.java:223) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:43) 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(Thre
[jira] [Comment Edited] (LUCENE-5945) Full cutover to Path api from java.io.File
[
https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132943#comment-14132943
]
Uwe Schindler edited comment on LUCENE-5945 at 9/13/14 8:50 PM:
Cool. Commit that shit, except a small improvement:
One small idea for forbidden-apis: ANT allows it to make parts of a fileset
conditionally. So you might make use the isLucene property when building the
fileset of signaturesfiles:
{code:xml}
{code}
This will speed up forbiddenapis, as it does not need to be exceuded multiple
times.
If you have quesions, I might take care tomorrow. I found out that if/unless
works with filesets include directive only a few days ago:
[https://ant.apache.org/manual/Types/patternset.html]
was (Author: thetaphi):
Cool. Commit that shit, except a small improvement:
One small idea for forbidden-apis: ANT allows it to make parts of a fileset
conditionally. So you might make use the isLucene property when building the
fileset of signaturesfiles:
{code:xml}
{code}
This will speed up forbiddenapis, as it does not need to be exceuded multiple
times.
If you have quesions, I might take care tomorrow. I found out that if/unless
works with filesets include directive only a few days ago:
[https://ant.apache.org/manual/Types/patternset.html]
> Full cutover to Path api from java.io.File
> --
>
> Key: LUCENE-5945
> URL: https://issues.apache.org/jira/browse/LUCENE-5945
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
> Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch
>
>
> Using NIO2 has a lot of benefits:
> * more fine grained exception handling
> * clearer semantics about what happens
> * additional functionality
> * possibility to work with virtual filesystems, etc.
> We already banned File.delete and switched to Files.delete, I think we should
> ban File completely (except for some sugar methods that just forward with
> .toPath, like FSDirectory.open)
> For tests, ideally we go a little further and ban methods like
> FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure
> all Paths are created via one protected method. This leaves open the
> possibility to mock up filesystem behavior at a lower level in tests in the
> future.
--
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-5945) Full cutover to Path api from java.io.File
[
https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132943#comment-14132943
]
Uwe Schindler commented on LUCENE-5945:
---
Cool. Commit that shit, except a small improvement:
One small idea for forbidden-apis: ANT allows it to make parts of a fileset
conditionally. So you might make use the isLucene property when building the
fileset of signaturesfiles:
{code:xml}
{code}
This will speed up forbiddenapis, as it does not need to be exceuded multiple
times.
If you have quesions, I might take care tomorrow. I found out that if/unless
works with filesets include directive only a few days ago:
[https://ant.apache.org/manual/Types/patternset.html]
> Full cutover to Path api from java.io.File
> --
>
> Key: LUCENE-5945
> URL: https://issues.apache.org/jira/browse/LUCENE-5945
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
> Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch
>
>
> Using NIO2 has a lot of benefits:
> * more fine grained exception handling
> * clearer semantics about what happens
> * additional functionality
> * possibility to work with virtual filesystems, etc.
> We already banned File.delete and switched to Files.delete, I think we should
> ban File completely (except for some sugar methods that just forward with
> .toPath, like FSDirectory.open)
> For tests, ideally we go a little further and ban methods like
> FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure
> all Paths are created via one protected method. This leaves open the
> possibility to mock up filesystem behavior at a lower level in tests in the
> future.
--
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-5930) IntelliJ config: drop resource-only modules, add module groups, and add module for lucene/backward-codecs
[ https://issues.apache.org/jira/browse/LUCENE-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132933#comment-14132933 ] ASF subversion and git services commented on LUCENE-5930: - Commit 1624780 from [~sar...@syr.edu] in branch 'dev/trunk' [ https://svn.apache.org/r1624780 ] LUCENE-5930: native svn:eol-style for new file backward-codecs.iml > IntelliJ config: drop resource-only modules, add module groups, and add > module for lucene/backward-codecs > - > > Key: LUCENE-5930 > URL: https://issues.apache.org/jira/browse/LUCENE-5930 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ryan Ernst >Assignee: Steve Rowe > Fix For: 4.11, 5.0 > > Attachments: > LUCENE-5930.failed.intellij.map-reduce.module.test.output.txt, > LUCENE-5930.patch, LUCENE-5930.patch, LUCENE-5930.patch, LUCENE-5930.patch, > LUCENE-5930.patch > > > The number of intellij modules is getting out of hand. Intellij supports > marking subdirectories within a module as > source/resources/tests/test-resources. I think we should consolidate these > modules so we have just one per lucene module. Is there some reason I'm > missing that this was not done in the first place? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b28) - Build # 11239 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11239/ Java: 64bit/jdk1.9.0-ea-b28 -XX:-UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 50578 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:491: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:430: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:105: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:204: The following files are missing svn:eol-style (or binary svn:mime-type): * ./dev-tools/idea/lucene/backward-codecs/backward-codecs.iml Total time: 99 minutes 10 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.9.0-ea-b28 -XX:-UseCompressedOops -XX:+UseParallelGC Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5945) Full cutover to Path api from java.io.File
[ https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132877#comment-14132877 ] Michael McCandless commented on LUCENE-5945: This looks great, +1! We can iterate if there are issues ... > Full cutover to Path api from java.io.File > -- > > Key: LUCENE-5945 > URL: https://issues.apache.org/jira/browse/LUCENE-5945 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch > > > Using NIO2 has a lot of benefits: > * more fine grained exception handling > * clearer semantics about what happens > * additional functionality > * possibility to work with virtual filesystems, etc. > We already banned File.delete and switched to Files.delete, I think we should > ban File completely (except for some sugar methods that just forward with > .toPath, like FSDirectory.open) > For tests, ideally we go a little further and ban methods like > FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure > all Paths are created via one protected method. This leaves open the > possibility to mock up filesystem behavior at a lower level in tests in the > future. -- 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-5945) Full cutover to Path api from java.io.File
[ https://issues.apache.org/jira/browse/LUCENE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5945: Attachment: LUCENE-5945.patch Here is a more fleshed out patch. All tests pass and java.io.File/FileInputStream/FileOutputStream are banned. I think its ready for trunk, we can iterate with more improvements and cleanups after. > Full cutover to Path api from java.io.File > -- > > Key: LUCENE-5945 > URL: https://issues.apache.org/jira/browse/LUCENE-5945 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Attachments: LUCENE-5945.patch, LUCENE-5945_core.patch > > > Using NIO2 has a lot of benefits: > * more fine grained exception handling > * clearer semantics about what happens > * additional functionality > * possibility to work with virtual filesystems, etc. > We already banned File.delete and switched to Files.delete, I think we should > ban File completely (except for some sugar methods that just forward with > .toPath, like FSDirectory.open) > For tests, ideally we go a little further and ban methods like > FileSystems.getDefault(). Instead we could exempt LuceneTestCase and ensure > all Paths are created via one protected method. This leaves open the > possibility to mock up filesystem behavior at a lower level in tests in the > future. -- 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-5473) Split clusterstate.json per collection and watch states selectively
[ https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132858#comment-14132858 ] ASF subversion and git services commented on SOLR-5473: --- Commit 1624770 from [~noble.paul] in branch 'dev/trunk' [ https://svn.apache.org/r1624770 ] SOLR-5473 removed unused APi, logging > Split clusterstate.json per collection and watch states selectively > > > Key: SOLR-5473 > URL: https://issues.apache.org/jira/browse/SOLR-5473 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Noble Paul >Assignee: Noble Paul > Labels: SolrCloud > Fix For: 4.10, 5.0 > > Attachments: SOLR-5473-74 .patch, SOLR-5473-74.patch, > SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, > SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, > SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, > SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, > SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, > SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, > SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, > SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, > SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, > SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, > SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74_POC.patch, > SOLR-5473-configname-fix.patch, SOLR-5473.patch, SOLR-5473.patch, > SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, > SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, > SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, > SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, > SOLR-5473.patch, SOLR-5473.patch, SOLR-5473_no_ui.patch, > SOLR-5473_undo.patch, ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log > > > As defined in the parent issue, store the states of each collection under > /collections/collectionname/state.json node and watches state changes > selectively. > https://reviews.apache.org/r/24220/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b28) - Build # 11238 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11238/ Java: 32bit/jdk1.9.0-ea-b28 -client -XX:+UseSerialGC All tests passed Build Log: [...truncated 31784 lines...] -check-forbidden-all: [forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.7 [forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.7 [forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.3 [forbidden-apis] Reading API signatures: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/base.txt [forbidden-apis] Reading API signatures: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/servlet-api.txt [forbidden-apis] Loading classes to check... [forbidden-apis] Scanning for API signatures and dependencies... [forbidden-apis] Forbidden method invocation: java.lang.String#(byte[]) [Uses default charset] [forbidden-apis] in org.apache.solr.cloud.Overseer$ClusterStateUpdater (Overseer.java:316) [forbidden-apis] Scanned 2357 (and 1560 related) class file(s) for forbidden API invocations (in 1.54s), 1 error(s). BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:491: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:85: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:271: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:479: Check for forbidden API calls failed, see log. Total time: 109 minutes 6 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 32bit/jdk1.9.0-ea-b28 -client -XX:+UseSerialGC Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move trunk to Java 8
: > : faster. And there are a ton of features that would make our lives as : > : developers easier (and that can improve the quality of Lucene 5 when : > : it is eventually released). : > : > Examples please? : The ability to specify default methods on interfaces. So far, that's the only concrete example of seen of the stated motivation for this proposal. It doesn't strike me as a Game Changing langauge feature worthy of making the jump -- Not stacked up against the concerns expressed by several people about alienating existing users. I'm not opposed to moving to Java8, i'm just opposed to doing it w/o more compelling reasons. -1 ... unless/until there are more examples of: a) how moving to java 8 will make our lives easier; b) how java 8 will improve the quality of Lucene. -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_20) - Build # 4309 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4309/ Java: 64bit/jdk1.8.0_20 -XX:+UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 31708 lines...] -check-forbidden-all: [forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.7 [forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.7 [forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.3 [forbidden-apis] Reading API signatures: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\tools\forbiddenApis\base.txt [forbidden-apis] Reading API signatures: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\tools\forbiddenApis\servlet-api.txt [forbidden-apis] Loading classes to check... [forbidden-apis] Scanning for API signatures and dependencies... [forbidden-apis] Forbidden method invocation: java.lang.String#(byte[]) [Uses default charset] [forbidden-apis] in org.apache.solr.cloud.Overseer$ClusterStateUpdater (Overseer.java:316) [forbidden-apis] Scanned 2357 (and 1560 related) class file(s) for forbidden API invocations (in 3.45s), 1 error(s). BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:491: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:85: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build.xml:271: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\common-build.xml:479: Check for forbidden API calls failed, see log. Total time: 177 minutes 21 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.8.0_20 -XX:+UseCompressedOops -XX:+UseG1GC Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b28) - Build # 11237 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11237/ Java: 64bit/jdk1.9.0-ea-b28 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. REGRESSION: org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.testDistribSearch Error Message: No live SolrServers available to handle this request:[http://127.0.0.1:59445, http://127.0.0.1:41238, http://127.0.0.1:49769] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:59445, http://127.0.0.1:41238, http://127.0.0.1:49769] at __randomizedtesting.SeedInfo.seed([A4B8794CEC9E772E:255EF7549BC11712]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:322) at org.apache.solr.client.solrj.impl.CloudSolrServer.sendRequest(CloudSolrServer.java:874) at org.apache.solr.client.solrj.impl.CloudSolrServer.requestWithRetryOnStaleState(CloudSolrServer.java:658) at org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:601) at org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.removeAndWaitForLastReplicaGone(DeleteLastCustomShardedReplicaTest.java:116) at org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.doTest(DeleteLastCustomShardedReplicaTest.java:106) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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:484) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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)
[JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build # 11236 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11236/
Java: 32bit/ibm-j9-jdk7
-Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/lucene/util/fst/FST;}
1 tests failed.
REGRESSION: org.apache.solr.cloud.SyncSliceTest.testDistribSearch
Error Message:
expected:<5> but was:<4>
Stack Trace:
java.lang.AssertionError: expected:<5> but was:<4>
at
__randomizedtesting.SeedInfo.seed([C9793CC7A981939A:489FB2DFDEDEF3A6]: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.cloud.SyncSliceTest.doTest(SyncSliceTest.java:176)
at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:619)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:43)
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.j
[JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4848 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4848/ 2 tests failed. REGRESSION: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.testDistribSearch Error Message: There were too many update fails - we expect it can happen, but shouldn't easily Stack Trace: java.lang.AssertionError: There were too many update fails - we expect it can happen, but shouldn't easily at __randomizedtesting.SeedInfo.seed([D770CC88A35EAAC8:56964290D401CAF4]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.doTest(ChaosMonkeyNothingIsSafeTest.java:223) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:43) 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
[jira] [Commented] (LUCENE-5941) IndexWriter.forceMerge documentation error
[ https://issues.apache.org/jira/browse/LUCENE-5941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132616#comment-14132616 ] Robert Muir commented on LUCENE-5941: - Thats just not true Shai. I think you shoudl look at the CFS building code. On unix, it will always be deleted. > IndexWriter.forceMerge documentation error > -- > > Key: LUCENE-5941 > URL: https://issues.apache.org/jira/browse/LUCENE-5941 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Shai Erera >Assignee: Shai Erera > Attachments: LUCENE-5941.patch > > > IndexWriter.forceMerge documents that it requires up to 3X *FREE* space in > order to run successfully. We even go further with it and test it in > TestIWForceMerge.testForceMergeTempSpaceUsage(). But I think that's wrong. I > cannot think of a situation where we consume 3X *additional* space during > merge: > * 1X - that's the source segments to be merged > * 2X - that's the result non-CFS merged segment > * 3X - that's the CFS creation > At no point do we publish the non-CFS merged segment, therefore the merge, as > I understand it, only consumes up to 2X additional space during that merge. > And anyway, we only require 2X of additional space of the *largest* merge (or > total batch of running merges, depends on your MergeScheduler), not the whole > index size. This is an important observation, since if you e.g. have a 500GB > index, users shouldn't think they need to reserve an additional 1TB for > merging, since most of their big segments won't be merged by default anyway > (TieredMP defaults to 5GB largest segment). > I'll post a patch which fixes the documentation and the test. If anyone can > think of a scenario where we consume up to 3X *additional* space, please > chime, and I'll only modify IW.forceMerge documentation to explain that. -- 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: [VOTE] Move trunk to Java 8
On Sat, Sep 13, 2014 at 1:46 AM, Erick Erickson wrote: > The point remains that the end user users who are _not_ developers > of Lucene/Solr are our "customers". Otherwise we're all just playing > with ourselves. Not true. Lucene is a library. 100% of its users are developers. - 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 # 626 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/626/ 2 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch Error Message: shard1 is not consistent. Got 422 from http://127.0.0.1:48691/v/cm/collection1lastClient and got 196 from http://127.0.0.1:50084/v/cm/collection1 Stack Trace: java.lang.AssertionError: shard1 is not consistent. Got 422 from http://127.0.0.1:48691/v/cm/collection1lastClient and got 196 from http://127.0.0.1:50084/v/cm/collection1 at __randomizedtesting.SeedInfo.seed([7CCBC26355A09FF5:FD2D4C7B22C9]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1169) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1148) at org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.doTest(ChaosMonkeySafeLeaderTest.java:162) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at
[jira] [Commented] (SOLR-6514) SyncSliceTest on trunk is failing consistently
[
https://issues.apache.org/jira/browse/SOLR-6514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132607#comment-14132607
]
ASF subversion and git services commented on SOLR-6514:
---
Commit 1624717 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1624717 ]
SOLR-6514
> SyncSliceTest on trunk is failing consistently
> --
>
> Key: SOLR-6514
> URL: https://issues.apache.org/jira/browse/SOLR-6514
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.0
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Attachments: SOLR-6514.patch, SOLR-6514.patch
>
>
> With our without a repro seed, SyncSliceTest is failing all the time for me:
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=SyncSliceTest
> -Dtests.method=testDistribSearch -Dtests.seed=2CA4CC8B262333A5
> -Dtests.slow=true -Dtests.locale=es_HN -Dtests.timezone=America/Sitka
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 62.7s | SyncSliceTest.testDistribSearch <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<5> but
> was:<4>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([2CA4CC8B262333A5:AD424293517C5399]:0)
>[junit4]> at
> org.apache.solr.cloud.SyncSliceTest.doTest(SyncSliceTest.java:176)
>[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869)
>[junit4]> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Also, see today's Policeman Jenkins failure:
> http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11231/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 1828 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1828/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.solr.cloud.SyncSliceTest.testDistribSearch Error Message: expected:<5> but was:<4> Stack Trace: java.lang.AssertionError: expected:<5> but was:<4> at __randomizedtesting.SeedInfo.seed([F0754BD343A970FA:7193C5CB34F610C6]: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.cloud.SyncSliceTest.doTest(SyncSliceTest.java:176) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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:43) 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.lan
