[jira] [Commented] (SOLR-6385) Strange behavior on indexing document with wrong date format
[ https://issues.apache.org/jira/browse/SOLR-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108280#comment-14108280 ] Denis Shishlyannikoc commented on SOLR-6385: Hello guys. Thank you for quick response. Can I have here link to place in dev mailing list where this issue was commented? Thank you! Strange behavior on indexing document with wrong date format Key: SOLR-6385 URL: https://issues.apache.org/jira/browse/SOLR-6385 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 4.7.2 Environment: Solr server in Windows 7, solrj Reporter: Denis Shishlyannikoc Priority: Critical Hello. I try to work with solr lately and did not get much experience with it yet, so part of problems that I will describe here can be due to lack of knowledge. Excuse me for that. Problems that I saw: 1) I use solj to index collection of SolrInputDocuments. To do it I call method add(Collection) of CloudSolrServer object. Just for fun I tried to index one of documents with not correct date: I took solr valid date value of one of these SolrInputDocuments and changed the T symbol in it to K. (this date is defined in schema.xml as field name=mydate type=tdate indexed=true stored=true multiValued=false / ) Solr failed to index collection and returned SolrServerException. Also what happened above is that part of documents of this SolrInputDocuments collection got indexed correctly, problematic date document failed to be indexed together with several valid (from all points of view) SolrInputDocuments of this collection. Looks like solr went through documents in collection, indexing them one by one, trowed exception on problematic date document and finally did not index all valid documents that were after problematic date document. 2) After failure, described in 1), solr kept problematic date document in some queue and tried to reindex this document again (attempt per some 3-5 minutes, did not measure exact time of that), showing same (failed to parse date) exception in logs! After solr server restart issue is gone: no more tries to reindex problematic date document. Questions to be answered 1) What is the default behavior of solr on indexing problematic values fields? For example for date field: I expect solr to index null date (instead of not indexing of whole document) and then write some warning to logs and return some indication of problem on UpdateResponse. Maybe solr behavior on not valid field values should be configurable (defined in some xml element in schema). 2) While indexing collection of documents, should solr index all valid documents (and not return on first problem as it happens now) ? If I index collection of documents, I expect solr to index all valid (from all points of view) documents and return indexing status on UpdateResponse about all not indexed problematic documents. 3) Why solr tries to reindex problematic document? Looks like bug that can create useless load on server. If this behavior is planned by design, then how can I force solr to stop reindexing such problem documents (without restarting of solr server)? Where can I read about it? Thank you. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6385) Strange behavior on indexing document with wrong date format
[ https://issues.apache.org/jira/browse/SOLR-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108281#comment-14108281 ] Denis Shishlyannikoc commented on SOLR-6385: Erick Erickson, can you be more specific when talking about other JIRAs? Thanks. Strange behavior on indexing document with wrong date format Key: SOLR-6385 URL: https://issues.apache.org/jira/browse/SOLR-6385 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 4.7.2 Environment: Solr server in Windows 7, solrj Reporter: Denis Shishlyannikoc Priority: Critical Hello. I try to work with solr lately and did not get much experience with it yet, so part of problems that I will describe here can be due to lack of knowledge. Excuse me for that. Problems that I saw: 1) I use solj to index collection of SolrInputDocuments. To do it I call method add(Collection) of CloudSolrServer object. Just for fun I tried to index one of documents with not correct date: I took solr valid date value of one of these SolrInputDocuments and changed the T symbol in it to K. (this date is defined in schema.xml as field name=mydate type=tdate indexed=true stored=true multiValued=false / ) Solr failed to index collection and returned SolrServerException. Also what happened above is that part of documents of this SolrInputDocuments collection got indexed correctly, problematic date document failed to be indexed together with several valid (from all points of view) SolrInputDocuments of this collection. Looks like solr went through documents in collection, indexing them one by one, trowed exception on problematic date document and finally did not index all valid documents that were after problematic date document. 2) After failure, described in 1), solr kept problematic date document in some queue and tried to reindex this document again (attempt per some 3-5 minutes, did not measure exact time of that), showing same (failed to parse date) exception in logs! After solr server restart issue is gone: no more tries to reindex problematic date document. Questions to be answered 1) What is the default behavior of solr on indexing problematic values fields? For example for date field: I expect solr to index null date (instead of not indexing of whole document) and then write some warning to logs and return some indication of problem on UpdateResponse. Maybe solr behavior on not valid field values should be configurable (defined in some xml element in schema). 2) While indexing collection of documents, should solr index all valid documents (and not return on first problem as it happens now) ? If I index collection of documents, I expect solr to index all valid (from all points of view) documents and return indexing status on UpdateResponse about all not indexed problematic documents. 3) Why solr tries to reindex problematic document? Looks like bug that can create useless load on server. If this behavior is planned by design, then how can I force solr to stop reindexing such problem documents (without restarting of solr server)? Where can I read about it? Thank you. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6385) Strange behavior on indexing document with wrong date format
[ https://issues.apache.org/jira/browse/SOLR-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108283#comment-14108283 ] Erick Erickson commented on SOLR-6385: -- https://issues.apache.org/jira/browse/SOLR-445 Strange behavior on indexing document with wrong date format Key: SOLR-6385 URL: https://issues.apache.org/jira/browse/SOLR-6385 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 4.7.2 Environment: Solr server in Windows 7, solrj Reporter: Denis Shishlyannikoc Priority: Critical Hello. I try to work with solr lately and did not get much experience with it yet, so part of problems that I will describe here can be due to lack of knowledge. Excuse me for that. Problems that I saw: 1) I use solj to index collection of SolrInputDocuments. To do it I call method add(Collection) of CloudSolrServer object. Just for fun I tried to index one of documents with not correct date: I took solr valid date value of one of these SolrInputDocuments and changed the T symbol in it to K. (this date is defined in schema.xml as field name=mydate type=tdate indexed=true stored=true multiValued=false / ) Solr failed to index collection and returned SolrServerException. Also what happened above is that part of documents of this SolrInputDocuments collection got indexed correctly, problematic date document failed to be indexed together with several valid (from all points of view) SolrInputDocuments of this collection. Looks like solr went through documents in collection, indexing them one by one, trowed exception on problematic date document and finally did not index all valid documents that were after problematic date document. 2) After failure, described in 1), solr kept problematic date document in some queue and tried to reindex this document again (attempt per some 3-5 minutes, did not measure exact time of that), showing same (failed to parse date) exception in logs! After solr server restart issue is gone: no more tries to reindex problematic date document. Questions to be answered 1) What is the default behavior of solr on indexing problematic values fields? For example for date field: I expect solr to index null date (instead of not indexing of whole document) and then write some warning to logs and return some indication of problem on UpdateResponse. Maybe solr behavior on not valid field values should be configurable (defined in some xml element in schema). 2) While indexing collection of documents, should solr index all valid documents (and not return on first problem as it happens now) ? If I index collection of documents, I expect solr to index all valid (from all points of view) documents and return indexing status on UpdateResponse about all not indexed problematic documents. 3) Why solr tries to reindex problematic document? Looks like bug that can create useless load on server. If this behavior is planned by design, then how can I force solr to stop reindexing such problem documents (without restarting of solr server)? Where can I read about it? Thank you. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 4.10.0 RC0
+1 SUCCESS! [0:54:10.259684] Steve On Aug 22, 2014, at 8:08 PM, Ryan Ernst r...@iernst.net wrote: Please vote for the first release candidate for Lucene/Solr 4.10.0. The artifacts can be downloaded here: http://people.apache.org/~rjernst/staging_area/lucene-solr-4.10.0-RC0-rev1619858 Or you can run the smoker tester directly with this command line (assuming you have JAVA7_HOME set): python3.2 -u dev-tools/scripts/smokeTestRelease.py http://people.apache.org/~rjernst/staging_area/lucene-solr-4.10.0-RC0-rev1619858 1619858 4.10.0 /tmp/smoke_test_4_10 Please note, the RC number is starting at 0 because I used the sample command line in buildAndPushRelease.py. If there is another release, I will jump to RC2 to avoid confusion (thus it would be the second RC). I also plan to open an issue to clean up some things about buildAndPushRelease.py help (or lack there of). SUCCESS! [0:35:20.208893] Here is my +1 Thanks, Ryan - 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
[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.8.0) - Build # 1751 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1751/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 47213 lines...] changes-to-html: [mkdir] Created dir: /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/docs/changes [get] Getting: https://issues.apache.org/jira/rest/api/2/project/LUCENE [get] To: /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/docs/changes/jiraVersionList.json [exec] Bareword found where operator expected at (eval 1) line 3, near titleSystem [exec] (Missing operator before System?) [exec] ERROR eval'ing munged JSON string ||html [exec] head [exec] titleSystem Maintenance/title [exec] /head [exec] body [exec] h1Maintenance in progress/h1 [exec] pThis system is currently down for maintenance. More details may be [exec] available from the a href='http://monitoring.apache.org/status/' [exec] ASF Public Network Status/a page./p [exec] /body [exec] /html [exec] ||: Can't find string terminator ' anywhere before EOF at (eval 1) line 8. [exec] BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/build.xml:485: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/build.xml:66: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build.xml:212: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build.xml:548: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/common-build.xml:2442: exec returned: 255 Total time: 192 minutes 50 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.8.0 -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-Windows (64bit/jdk1.8.0_20) - Build # 4269 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4269/ Java: 64bit/jdk1.8.0_20 -XX:+UseCompressedOops -XX:+UseSerialGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.rest.TestManagedResourceStorage Error Message: SolrCore.getOpenCount()==2 Stack Trace: java.lang.RuntimeException: SolrCore.getOpenCount()==2 at __randomizedtesting.SeedInfo.seed([AB11A7F41A33E32A]:0) at org.apache.solr.util.TestHarness.close(TestHarness.java:332) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:633) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:184) at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source) 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$5.evaluate(RandomizedRunner.java:790) 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.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.rest.TestManagedResourceStorage Error Message: 4 threads leaked from SUITE scope at org.apache.solr.rest.TestManagedResourceStorage: 1) Thread[id=7655, name=searcherExecutor-4302-thread-1, state=WAITING, group=TGRP-TestManagedResourceStorage] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)2) Thread[id=7658, name=coreZkRegister-4296-thread-1, state=WAITING, group=TGRP-TestManagedResourceStorage] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)3) Thread[id=7656, name=Thread-3035, state=WAITING, group=TGRP-TestManagedResourceStorage] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at org.apache.solr.core.CloserThread.run(CoreContainer.java:905)4) Thread[id=7652,
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_67) - Build # 11093 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11093/ Java: 64bit/jdk1.7.0_67 -XX:-UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 46509 lines...] -documentation-lint: [echo] checking for broken html... [jtidy] Checking for broken html (such as invalid tags)... [delete] Deleting directory /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/jtidy_tmp [echo] Checking for broken links... [exec] [exec] Crawl/parse... [exec] [exec] Verify... [echo] Checking for missing docs... [exec] [exec] build/docs/classification/org/apache/lucene/classification/SimpleNaiveBayesClassifier.html [exec] missing Fields: atomicReader [exec] [exec] Missing javadocs were found! BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:485: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:66: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:212: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:242: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:2419: exec returned: 1 Total time: 115 minutes 31 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.7.0_67 -XX:-UseCompressedOops -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
[jira] [Commented] (LUCENE-5699) Lucene classification score calculation normalize and return lists
[ https://issues.apache.org/jira/browse/LUCENE-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108405#comment-14108405 ] ASF subversion and git services commented on LUCENE-5699: - Commit 1620122 from [~teofili] in branch 'dev/trunk' [ https://svn.apache.org/r1620122 ] LUCENE-5699 - added missing javadoc for atomic reader Lucene classification score calculation normalize and return lists -- Key: LUCENE-5699 URL: https://issues.apache.org/jira/browse/LUCENE-5699 Project: Lucene - Core Issue Type: Sub-task Components: modules/classification Reporter: Gergő Törcsvári Assignee: Tommaso Teofili Labels: gsoc2014 Fix For: 5.0, 4.11 Attachments: 06-06-5699.patch, 0730.patch, 0803-base.patch, 0810-base.patch Now the classifiers can return only the best matching classes. If somebody want it to use more complex tasks he need to modify these classes for get second and third results too. If it is possible to return a list and it is not a lot resource why we dont do that? (We iterate a list so also.) The Bayes classifier get too small return values, and there were a bug with the zero floats. It was fixed with logarithmic. It would be nice to scale the class scores sum vlue to one, and then we coud compare two documents return score and relevance. (If we dont do this the wordcount in the test documents affected the result score.) With bulletpoints: * In the Bayes classification normalized score values, and return with result lists. * In the KNN classifier possibility to return a result list. * Make the ClassificationResult Comparable for list sorting. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.8.0_20) - Build # 4176 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/4176/ Java: 32bit/jdk1.8.0_20 -client -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestSolrIndexConfig Error Message: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\solr\build\solr-core\test\J0\.\temp\solr.core.TestSolrIndexConfig-A9D7B5FD5C6361D2-001\tempDir-001\infostream.txt C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\solr\build\solr-core\test\J0\.\temp\solr.core.TestSolrIndexConfig-A9D7B5FD5C6361D2-001\tempDir-001 C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\solr\build\solr-core\test\J0\.\temp\solr.core.TestSolrIndexConfig-A9D7B5FD5C6361D2-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\solr\build\solr-core\test\J0\.\temp\solr.core.TestSolrIndexConfig-A9D7B5FD5C6361D2-001\tempDir-001\infostream.txt C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\solr\build\solr-core\test\J0\.\temp\solr.core.TestSolrIndexConfig-A9D7B5FD5C6361D2-001\tempDir-001 C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\solr\build\solr-core\test\J0\.\temp\solr.core.TestSolrIndexConfig-A9D7B5FD5C6361D2-001 at __randomizedtesting.SeedInfo.seed([A9D7B5FD5C6361D2]:0) at org.apache.lucene.util.TestUtil.rm(TestUtil.java:117) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:125) 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 11802 lines...] [junit4] Suite: org.apache.solr.core.TestSolrIndexConfig [junit4] 2 Creating dataDir: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\solr\build\solr-core\test\J0\.\temp\solr.core.TestSolrIndexConfig-A9D7B5FD5C6361D2-001\init-core-data-001 [junit4] 2 4770794 T11990 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl (true) and clientAuth (true) [junit4] 2 4770796 T11990 oas.SolrTestCaseJ4.initCore initCore [junit4] 2 4770797 T11990 oasc.SolrResourceLoader.init new SolrResourceLoader for directory: 'C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\solr\core\src\test-files\solr\collection1\' [junit4] 2 4770799 T11990 oasc.SolrResourceLoader.replaceClassLoader Adding 'file:/C:/Users/JenkinsSlave/workspace/Lucene-Solr-4.x-Windows/solr/core/src/test-files/solr/collection1/lib/.svn/' to classloader [junit4] 2 4770801 T11990 oasc.SolrResourceLoader.replaceClassLoader Adding 'file:/C:/Users/JenkinsSlave/workspace/Lucene-Solr-4.x-Windows/solr/core/src/test-files/solr/collection1/lib/classes/' to classloader [junit4] 2 4770801 T11990 oasc.SolrResourceLoader.replaceClassLoader Adding 'file:/C:/Users/JenkinsSlave/workspace/Lucene-Solr-4.x-Windows/solr/core/src/test-files/solr/collection1/lib/README' to classloader [junit4] 2 4770852 T11990 oasu.SolrIndexConfig.init WARN IndexWriter infoStream file log is enabled: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\solr\build\solr-core\test\J0\.\temp\solr.core.TestSolrIndexConfig-A9D7B5FD5C6361D2-001\tempDir-001/infostream.txt [junit4] 2This feature is deprecated. Remove @file from infoStream to output messages to solr's logfile [junit4] 2 4770854 T11990 oasc.SolrConfig.init Using Lucene MatchVersion: 4.11.0 [junit4] 2 4770860 T11990 oasc.SolrConfig.init Loaded SolrConfig: solrconfig-indexconfig.xml [junit4] 2 4770861 T11990 oass.IndexSchema.readSchema Reading Solr Schema from schema.xml [junit4] 2 4770871 T11990 oass.IndexSchema.readSchema [null] Schema name=test [junit4] 2 4771038 T11990 oass.ByteField.init WARN ByteField is deprecated and will be removed in 5.0. You should use TrieIntField instead. [junit4] 2 4771038 T11990 oass.ShortField.init WARN ShortField is deprecated and will be removed in 5.0. You should use TrieIntField
Re: [VOTE] 4.10.0 RC0
+1 SUCCESS! [1:20:22.712616] On Sun, Aug 24, 2014 at 12:29 PM, Steve Rowe sar...@gmail.com wrote: +1 SUCCESS! [0:54:10.259684] Steve On Aug 22, 2014, at 8:08 PM, Ryan Ernst r...@iernst.net wrote: Please vote for the first release candidate for Lucene/Solr 4.10.0. The artifacts can be downloaded here: http://people.apache.org/~rjernst/staging_area/lucene-solr-4.10.0-RC0-rev1619858 Or you can run the smoker tester directly with this command line (assuming you have JAVA7_HOME set): python3.2 -u dev-tools/scripts/smokeTestRelease.py http://people.apache.org/~rjernst/staging_area/lucene-solr-4.10.0-RC0-rev1619858 1619858 4.10.0 /tmp/smoke_test_4_10 Please note, the RC number is starting at 0 because I used the sample command line in buildAndPushRelease.py. If there is another release, I will jump to RC2 to avoid confusion (thus it would be the second RC). I also plan to open an issue to clean up some things about buildAndPushRelease.py help (or lack there of). SUCCESS! [0:35:20.208893] Here is my +1 Thanks, Ryan - 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 -- Regards, Shalin Shekhar Mangar.
[JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4814 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4814/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestBackwardsCompatibility.testUpgradeOldSingleSegmentIndexWithAdditions Error Message: file _8.fdx was already written to Stack Trace: java.io.IOException: file _8.fdx was already written to at __randomizedtesting.SeedInfo.seed([CD1E08778E5DAA4A:9373618C3018B013]:0) at org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:495) at org.apache.lucene.store.TrackingDirectoryWrapper.createOutput(TrackingDirectoryWrapper.java:44) at org.apache.lucene.codecs.compressing.CompressingStoredFieldsWriter.init(CompressingStoredFieldsWriter.java:113) at org.apache.lucene.codecs.compressing.CompressingStoredFieldsFormat.fieldsWriter(CompressingStoredFieldsFormat.java:120) at org.apache.lucene.index.SegmentMerger.mergeFields(SegmentMerger.java:201) at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:95) at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3993) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3588) at org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40) at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1884) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1700) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1653) at org.apache.lucene.index.IndexUpgrader.upgrade(IndexUpgrader.java:165) at org.apache.lucene.index.TestBackwardsCompatibility.testUpgradeOldSingleSegmentIndexWithAdditions(TestBackwardsCompatibility.java:1045) 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 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 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
[jira] [Updated] (SOLR-6411) The leader replacement process should no longer be so strict that only a previously active replica can become leader.
[ https://issues.apache.org/jira/browse/SOLR-6411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-6411: -- Attachment: SOLR-6411.patch The leader replacement process should no longer be so strict that only a previously active replica can become leader. - Key: SOLR-6411 URL: https://issues.apache.org/jira/browse/SOLR-6411 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Attachments: SOLR-6411.patch, SOLR-6411.patch, SOLR-6411.patch, SOLR-6411.patch -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6402) OverseerCollectionProcessor should not exit for ZK ConnectionLoss
[
https://issues.apache.org/jira/browse/SOLR-6402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller resolved SOLR-6402.
---
Resolution: Fixed
Thanks Jessica!
OverseerCollectionProcessor should not exit for ZK ConnectionLoss
-
Key: SOLR-6402
URL: https://issues.apache.org/jira/browse/SOLR-6402
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.8, 5.0
Reporter: Jessica Cheng Mallet
Assignee: Mark Miller
Fix For: 5.0, 4.10
We saw an occurrence where we had some ZK connection blip and the
OverseerCollectionProcessor thread stopped but the ClusterStateUpdater output
some error but kept running, and the node didn't lose its leadership. this
caused our collection work queue to back up.
Right now OverseerCollectionProcessor's run method has on trunk:
{quote}
344 if (e.code() == KeeperException.Code.SESSIONEXPIRED
345 || e.code() == KeeperException.Code.CONNECTIONLOSS) \{
346 log.warn(Overseer cannot talk to ZK);
347 return;
348 \}
{quote}
I think this if statement should only be for SESSIONEXPIRED. If it just
experiences a connection loss but then reconnect before the session expired,
it'll keep being the leader.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6405) ZooKeeper calls can easily not be retried enough on ConnectionLoss.
[ https://issues.apache.org/jira/browse/SOLR-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-6405. --- Resolution: Fixed Thanks Jessica! ZooKeeper calls can easily not be retried enough on ConnectionLoss. --- Key: SOLR-6405 URL: https://issues.apache.org/jira/browse/SOLR-6405 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Priority: Critical Fix For: 5.0, 4.10 Attachments: SOLR-6405.patch The current design requires that we are sure we retry on connection loss until session expiration. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4814 - Still Failing
This will reproduce if you make the machine busy / beast it. I just tacked on -Dtests.dups=20 and it tripped once. I'll try to investigate... On Sun, Aug 24, 2014 at 9:42 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4814/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestBackwardsCompatibility.testUpgradeOldSingleSegmentIndexWithAdditions Error Message: file _8.fdx was already written to Stack Trace: java.io.IOException: file _8.fdx was already written to at __randomizedtesting.SeedInfo.seed([CD1E08778E5DAA4A:9373618C3018B013]:0) at org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:495) at org.apache.lucene.store.TrackingDirectoryWrapper.createOutput(TrackingDirectoryWrapper.java:44) at org.apache.lucene.codecs.compressing.CompressingStoredFieldsWriter.init(CompressingStoredFieldsWriter.java:113) at org.apache.lucene.codecs.compressing.CompressingStoredFieldsFormat.fieldsWriter(CompressingStoredFieldsFormat.java:120) at org.apache.lucene.index.SegmentMerger.mergeFields(SegmentMerger.java:201) at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:95) at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3993) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3588) at org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40) at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1884) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1700) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1653) at org.apache.lucene.index.IndexUpgrader.upgrade(IndexUpgrader.java:165) at org.apache.lucene.index.TestBackwardsCompatibility.testUpgradeOldSingleSegmentIndexWithAdditions(TestBackwardsCompatibility.java:1045) 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 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 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
[JENKINS] Lucene-Solr-SmokeRelease-trunk - Build # 194 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-trunk/194/
No tests ran.
Build Log:
[...truncated 50898 lines...]
prepare-release-no-sign:
[mkdir] Created dir:
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease
[copy] Copying 431 files to
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/lucene
[copy] Copying 230 files to
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/solr
[exec] JAVA7_HOME is /home/jenkins/tools/java/latest1.7
[exec] NOTE: output encoding is US-ASCII
[exec]
[exec] Load release URL
file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/...
[exec]
[exec] Test Lucene...
[exec] test basics...
[exec] get KEYS
[exec] 0.1 MB in 0.01 sec (14.1 MB/sec)
[exec] check changes HTML...
[exec] download lucene-5.0.0-src.tgz...
[exec] 27.3 MB in 0.04 sec (672.5 MB/sec)
[exec] verify md5/sha1 digests
[exec] download lucene-5.0.0.tgz...
[exec] 61.1 MB in 0.10 sec (641.8 MB/sec)
[exec] verify md5/sha1 digests
[exec] download lucene-5.0.0.zip...
[exec] 70.6 MB in 0.10 sec (689.0 MB/sec)
[exec] verify md5/sha1 digests
[exec] unpack lucene-5.0.0.tgz...
[exec] verify JAR metadata/identity/no javax.* or java.* classes...
[exec] test demo with 1.7...
[exec] got 5599 hits for query lucene
[exec] checkindex with 1.7...
[exec] check Lucene's javadoc JAR
[exec] unpack lucene-5.0.0.zip...
[exec] verify JAR metadata/identity/no javax.* or java.* classes...
[exec] test demo with 1.7...
[exec] got 5599 hits for query lucene
[exec] checkindex with 1.7...
[exec] check Lucene's javadoc JAR
[exec] unpack lucene-5.0.0-src.tgz...
[exec] Traceback (most recent call last):
[exec] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py,
line 1355, in module
[exec] main()
[exec] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py,
line 1299, in main
[exec] smokeTest(baseURL, svnRevision, version, tmpDir, isSigned,
testArgs)
[exec] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py,
line 1337, in smokeTest
[exec] unpackAndVerify('lucene', tmpDir, 'lucene-%s-src.tgz' %
version, svnRevision, version, testArgs, baseURL)
[exec] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py,
line 637, in unpackAndVerify
[exec] verifyUnpacked(project, artifact, unpackPath, svnRevision,
version, testArgs, tmpDir, baseURL)
[exec] File
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py,
line 708, in verifyUnpacked
[exec] raise RuntimeError('%s: unexpected files/dirs in artifact %s:
%s' % (project, artifact, l))
[exec] RuntimeError: lucene: unexpected files/dirs in artifact
lucene-5.0.0-src.tgz: ['version.properties']
BUILD FAILED
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/build.xml:405:
exec returned: 1
Total time: 18 minutes 21 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_67) - Build # 11094 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11094/ Java: 64bit/jdk1.7.0_67 -XX:+UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 46490 lines...] -documentation-lint: [echo] checking for broken html... [jtidy] Checking for broken html (such as invalid tags)... [delete] Deleting directory /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/jtidy_tmp [echo] Checking for broken links... [exec] [exec] Crawl/parse... [exec] [exec] Verify... [echo] Checking for missing docs... [exec] [exec] build/docs/suggest/org/apache/lucene/search/suggest/analyzing/AnalyzingInfixSuggester.html [exec] missing Methods: commit() [exec] [exec] Missing javadocs were found! BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:485: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:66: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:212: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:257: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:2419: exec returned: 1 Total time: 99 minutes 38 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.7.0_67 -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] (SOLR-6231) RollingRestartTest failures on jenkins
[
https://issues.apache.org/jira/browse/SOLR-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108420#comment-14108420
]
Mark Miller commented on SOLR-6231:
---
I think SOLR-6291 has addressed this.
RollingRestartTest failures on jenkins
--
Key: SOLR-6231
URL: https://issues.apache.org/jira/browse/SOLR-6231
Project: Solr
Issue Type: Bug
Components: SolrCloud, Tests
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Fix For: 5.0, 4.10
Attachments: SOLR-6231.patch
A somewhat rare fail on jenkins. An overseer was available to service
requests but even after waiting for 60 seconds, none of the designates were
the overseer.
{code}
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/4081/
Java: 32bit/jdk1.8.0_20-ea-b21 -client -XX:+UseSerialGC
1 tests failed.
REGRESSION: org.apache.solr.cloud.RollingRestartTest.testDistribSearch
Error Message:
No overseer designate as leader found after restart #3: 127.0.0.1:60996_
Stack Trace:
java.lang.AssertionError: No overseer designate as leader found after restart
#3: 127.0.0.1:60996_
at
__randomizedtesting.SeedInfo.seed([5263BF570390CF79:D385314F74CFAF45]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:100)
at
org.apache.solr.cloud.RollingRestartTest.doTest(RollingRestartTest.java:61)
at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:865)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6412) Speed up OverseerRolesTest for non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-6412: -- Issue Type: Sub-task (was: Test) Parent: SOLR-6293 Speed up OverseerRolesTest for non nightly runs. Key: SOLR-6412 URL: https://issues.apache.org/jira/browse/SOLR-6412 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller Priority: Minor -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6412) Speed up OverseerRolesTest for non nightly runs.
Mark Miller created SOLR-6412: - Summary: Speed up OverseerRolesTest for non nightly runs. Key: SOLR-6412 URL: https://issues.apache.org/jira/browse/SOLR-6412 Project: Solr Issue Type: Test Components: Tests Reporter: Mark Miller Assignee: Mark Miller Priority: Minor -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6412) Speed up OverseerRolesTest for non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108422#comment-14108422 ] ASF subversion and git services commented on SOLR-6412: --- Commit 1620140 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1620140 ] SOLR-6412: Speed up OverseerRolesTest for non nightly runs. Speed up OverseerRolesTest for non nightly runs. Key: SOLR-6412 URL: https://issues.apache.org/jira/browse/SOLR-6412 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller Priority: Minor -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6412) Speed up OverseerRolesTest for non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108424#comment-14108424 ] ASF subversion and git services commented on SOLR-6412: --- Commit 1620141 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1620141 ] SOLR-6412: Speed up OverseerRolesTest for non nightly runs. Speed up OverseerRolesTest for non nightly runs. Key: SOLR-6412 URL: https://issues.apache.org/jira/browse/SOLR-6412 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller Priority: Minor -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6413) Speed up TriLevelCompositeIdRoutingTest for non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-6413: -- Issue Type: Sub-task (was: Test) Parent: SOLR-6293 Speed up TriLevelCompositeIdRoutingTest for non nightly runs. - Key: SOLR-6413 URL: https://issues.apache.org/jira/browse/SOLR-6413 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6413) Speed up TriLevelCompositeIdRoutingTest for non nightly runs.
Mark Miller created SOLR-6413: - Summary: Speed up TriLevelCompositeIdRoutingTest for non nightly runs. Key: SOLR-6413 URL: https://issues.apache.org/jira/browse/SOLR-6413 Project: Solr Issue Type: Test Components: Tests Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4814 - Still Failing
I think its a bug, and this was just exposed by randomization of commitOnClose in IndexWriterConfig? we start a CMS merge for _8 segment (consumer creates _8.fdt and _8.fdx), but this merge doesn't make it into the commit, and we close() without waiting for merges. this merge is aborted and indexfiledeleter cleans up _8.fdt and _8.fdx we start a new IW on the same dir, and the next segment it tries to create is _8 (how else would it know?) which trips the double-write logic in createOutput. This logic currently only checks files that we ever created, and doesn't check if we ever deleted the file. We can fix mockdirectorywrapper, but I feel like this could be a real problem on e.g. windows if the file was busy for both IFD runs. On Sun, Aug 24, 2014 at 10:00 AM, Robert Muir rcm...@gmail.com wrote: This will reproduce if you make the machine busy / beast it. I just tacked on -Dtests.dups=20 and it tripped once. I'll try to investigate... On Sun, Aug 24, 2014 at 9:42 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4814/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestBackwardsCompatibility.testUpgradeOldSingleSegmentIndexWithAdditions Error Message: file _8.fdx was already written to Stack Trace: java.io.IOException: file _8.fdx was already written to at __randomizedtesting.SeedInfo.seed([CD1E08778E5DAA4A:9373618C3018B013]:0) at org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:495) at org.apache.lucene.store.TrackingDirectoryWrapper.createOutput(TrackingDirectoryWrapper.java:44) at org.apache.lucene.codecs.compressing.CompressingStoredFieldsWriter.init(CompressingStoredFieldsWriter.java:113) at org.apache.lucene.codecs.compressing.CompressingStoredFieldsFormat.fieldsWriter(CompressingStoredFieldsFormat.java:120) at org.apache.lucene.index.SegmentMerger.mergeFields(SegmentMerger.java:201) at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:95) at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3993) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3588) at org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40) at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1884) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1700) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1653) at org.apache.lucene.index.IndexUpgrader.upgrade(IndexUpgrader.java:165) at org.apache.lucene.index.TestBackwardsCompatibility.testUpgradeOldSingleSegmentIndexWithAdditions(TestBackwardsCompatibility.java:1045) 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 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
[jira] [Commented] (SOLR-6413) Speed up TriLevelCompositeIdRoutingTest for non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108425#comment-14108425 ] ASF subversion and git services commented on SOLR-6413: --- Commit 1620142 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1620142 ] SOLR-6413: Speed up TriLevelCompositeIdRoutingTest for non nightly runs. Speed up TriLevelCompositeIdRoutingTest for non nightly runs. - Key: SOLR-6413 URL: https://issues.apache.org/jira/browse/SOLR-6413 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6413) Speed up TriLevelCompositeIdRoutingTest for non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108426#comment-14108426 ] ASF subversion and git services commented on SOLR-6413: --- Commit 1620143 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1620143 ] SOLR-6413: Speed up TriLevelCompositeIdRoutingTest for non nightly runs. Speed up TriLevelCompositeIdRoutingTest for non nightly runs. - Key: SOLR-6413 URL: https://issues.apache.org/jira/browse/SOLR-6413 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - 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-tabpanelfocusedCommentId=14108427#comment-14108427 ] Mark Miller commented on SOLR-5473: --- bq. I need to finish documenting and tie up the mixed install stuff. Start of a release is a good time to get this in. I'll try and wrap up this up very shortly. 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: 5.0, 4.10 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_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.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5903) Fix MockDirectoryWrapper double-write logic?
Robert Muir created LUCENE-5903:
---
Summary: Fix MockDirectoryWrapper double-write logic?
Key: LUCENE-5903
URL: https://issues.apache.org/jira/browse/LUCENE-5903
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
From a jenkins failure:
{quote}
I think its a bug, and this was just exposed by randomization of
commitOnClose in IndexWriterConfig?
we start a CMS merge for _8 segment (consumer creates _8.fdt and
_8.fdx), but this merge doesn't make it into the commit, and we
close() without waiting for merges.
this merge is aborted and indexfiledeleter cleans up _8.fdt and _8.fdx
we start a new IW on the same dir, and the next segment it tries to
create is _8 (how else would it know?) which trips the double-write
logic in createOutput.
This logic currently only checks files that we ever created, and
doesn't check if we ever deleted the file.
We can fix mockdirectorywrapper, but I feel like this could be a real
problem on e.g. windows if the file was busy for both IFD runs.
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5903) Fix MockDirectoryWrapper double-write logic?
[
https://issues.apache.org/jira/browse/LUCENE-5903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-5903:
Attachment: LUCENE-5903_test.patch
Here is a (slow) but reproducible test. It just stalls the CMS merge thread
with a ratelimiter to force the abort.
Fix MockDirectoryWrapper double-write logic?
Key: LUCENE-5903
URL: https://issues.apache.org/jira/browse/LUCENE-5903
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Attachments: LUCENE-5903_test.patch
From a jenkins failure:
{quote}
I think its a bug, and this was just exposed by randomization of
commitOnClose in IndexWriterConfig?
we start a CMS merge for _8 segment (consumer creates _8.fdt and
_8.fdx), but this merge doesn't make it into the commit, and we
close() without waiting for merges.
this merge is aborted and indexfiledeleter cleans up _8.fdt and _8.fdx
we start a new IW on the same dir, and the next segment it tries to
create is _8 (how else would it know?) which trips the double-write
logic in createOutput.
This logic currently only checks files that we ever created, and
doesn't check if we ever deleted the file.
We can fix mockdirectorywrapper, but I feel like this could be a real
problem on e.g. windows if the file was busy for both IFD runs.
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6414) Update to Hadoop 2.5.0
Mark Miller created SOLR-6414: - Summary: Update to Hadoop 2.5.0 Key: SOLR-6414 URL: https://issues.apache.org/jira/browse/SOLR-6414 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.11 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5903) Fix MockDirectoryWrapper double-write logic?
[
https://issues.apache.org/jira/browse/LUCENE-5903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108432#comment-14108432
]
Robert Muir commented on LUCENE-5903:
-
I think its too hard to improve the situation for windows, its unavoidable
really. The best we could probably do is gobble up extra generations on IW
bootup to try to make it less likely.
As far as fixing MDW to allow for the situation (recording deleted files and
checking that map), it would be nice if somehow it would only allow this
across IW instances, but not within the same one.
Fix MockDirectoryWrapper double-write logic?
Key: LUCENE-5903
URL: https://issues.apache.org/jira/browse/LUCENE-5903
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Attachments: LUCENE-5903_test.patch
From a jenkins failure:
{quote}
I think its a bug, and this was just exposed by randomization of
commitOnClose in IndexWriterConfig?
we start a CMS merge for _8 segment (consumer creates _8.fdt and
_8.fdx), but this merge doesn't make it into the commit, and we
close() without waiting for merges.
this merge is aborted and indexfiledeleter cleans up _8.fdt and _8.fdx
we start a new IW on the same dir, and the next segment it tries to
create is _8 (how else would it know?) which trips the double-write
logic in createOutput.
This logic currently only checks files that we ever created, and
doesn't check if we ever deleted the file.
We can fix mockdirectorywrapper, but I feel like this could be a real
problem on e.g. windows if the file was busy for both IFD runs.
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6415) TestReplicationHandler is drastically slower than it used to be.
Mark Miller created SOLR-6415: - Summary: TestReplicationHandler is drastically slower than it used to be. Key: SOLR-6415 URL: https://issues.apache.org/jira/browse/SOLR-6415 Project: Solr Issue Type: Test Components: Tests Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6415) TestReplicationHandler is drastically slower than it used to be.
[ https://issues.apache.org/jira/browse/SOLR-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-6415: -- Issue Type: Sub-task (was: Test) Parent: SOLR-6293 TestReplicationHandler is drastically slower than it used to be. Key: SOLR-6415 URL: https://issues.apache.org/jira/browse/SOLR-6415 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4814 - Still Failing
I opened an issue: https://issues.apache.org/jira/browse/LUCENE-5903 It should not impact the release, as its an old situation and maybe nothing we can do to improve it, besides allowing MDW leniency for the case. On Sun, Aug 24, 2014 at 10:46 AM, Robert Muir rcm...@gmail.com wrote: I think its a bug, and this was just exposed by randomization of commitOnClose in IndexWriterConfig? we start a CMS merge for _8 segment (consumer creates _8.fdt and _8.fdx), but this merge doesn't make it into the commit, and we close() without waiting for merges. this merge is aborted and indexfiledeleter cleans up _8.fdt and _8.fdx we start a new IW on the same dir, and the next segment it tries to create is _8 (how else would it know?) which trips the double-write logic in createOutput. This logic currently only checks files that we ever created, and doesn't check if we ever deleted the file. We can fix mockdirectorywrapper, but I feel like this could be a real problem on e.g. windows if the file was busy for both IFD runs. On Sun, Aug 24, 2014 at 10:00 AM, Robert Muir rcm...@gmail.com wrote: This will reproduce if you make the machine busy / beast it. I just tacked on -Dtests.dups=20 and it tripped once. I'll try to investigate... On Sun, Aug 24, 2014 at 9:42 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4814/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestBackwardsCompatibility.testUpgradeOldSingleSegmentIndexWithAdditions Error Message: file _8.fdx was already written to Stack Trace: java.io.IOException: file _8.fdx was already written to at __randomizedtesting.SeedInfo.seed([CD1E08778E5DAA4A:9373618C3018B013]:0) at org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:495) at org.apache.lucene.store.TrackingDirectoryWrapper.createOutput(TrackingDirectoryWrapper.java:44) at org.apache.lucene.codecs.compressing.CompressingStoredFieldsWriter.init(CompressingStoredFieldsWriter.java:113) at org.apache.lucene.codecs.compressing.CompressingStoredFieldsFormat.fieldsWriter(CompressingStoredFieldsFormat.java:120) at org.apache.lucene.index.SegmentMerger.mergeFields(SegmentMerger.java:201) at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:95) at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3993) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3588) at org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40) at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1884) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1700) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1653) at org.apache.lucene.index.IndexUpgrader.upgrade(IndexUpgrader.java:165) at org.apache.lucene.index.TestBackwardsCompatibility.testUpgradeOldSingleSegmentIndexWithAdditions(TestBackwardsCompatibility.java:1045) 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 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
[jira] [Commented] (SOLR-6390) Remove unnecessary checked exception for CloudSolrServer constructor
[ https://issues.apache.org/jira/browse/SOLR-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108436#comment-14108436 ] ASF subversion and git services commented on SOLR-6390: --- Commit 1620146 from [~elyograg] in branch 'dev/trunk' [ https://svn.apache.org/r1620146 ] SOLR-6390: CloudSolrServer constructor improvements Remove unnecessary checked exception for CloudSolrServer constructor Key: SOLR-6390 URL: https://issues.apache.org/jira/browse/SOLR-6390 Project: Solr Issue Type: Improvement Reporter: Steve Davids Assignee: Shawn Heisey Priority: Trivial Fix For: 5.0, 4.11 Attachments: SOLR-6390.patch, SOLR-6390.patch, SOLR-6390.patch, SOLR-6390.patch The CloudSolrServer constructors can be simplified and can remove an unnecessary checked exception for one of the 4 constructors. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6415) TestReplicationHandler is drastically slower than it used to be.
[ https://issues.apache.org/jira/browse/SOLR-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108435#comment-14108435 ] Mark Miller commented on SOLR-6415: --- This is from separating out the tests in SOLR-4471. It brings the test for me from 30 seconds to over 200 seconds. I think we should switch back. TestReplicationHandler is drastically slower than it used to be. Key: SOLR-6415 URL: https://issues.apache.org/jira/browse/SOLR-6415 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6412) Speed up OverseerRolesTest for non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-6412. --- Resolution: Fixed Fix Version/s: 4.11 5.0 Speed up OverseerRolesTest for non nightly runs. Key: SOLR-6412 URL: https://issues.apache.org/jira/browse/SOLR-6412 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 5.0, 4.11 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6413) Speed up TriLevelCompositeIdRoutingTest for non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-6413. --- Resolution: Fixed Fix Version/s: 4.11 5.0 Speed up TriLevelCompositeIdRoutingTest for non nightly runs. - Key: SOLR-6413 URL: https://issues.apache.org/jira/browse/SOLR-6413 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.11 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6390) Remove unnecessary checked exception for CloudSolrServer constructor
[ https://issues.apache.org/jira/browse/SOLR-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108439#comment-14108439 ] Shawn Heisey commented on SOLR-6390: Right after I got the trunk commit done, I remembered that although I had started a precommit on trunk, I actually don't recall seeing whether it passed. Running it again before committing branch_4x. Remove unnecessary checked exception for CloudSolrServer constructor Key: SOLR-6390 URL: https://issues.apache.org/jira/browse/SOLR-6390 Project: Solr Issue Type: Improvement Reporter: Steve Davids Assignee: Shawn Heisey Priority: Trivial Fix For: 5.0, 4.11 Attachments: SOLR-6390.patch, SOLR-6390.patch, SOLR-6390.patch, SOLR-6390.patch The CloudSolrServer constructors can be simplified and can remove an unnecessary checked exception for one of the 4 constructors. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6416) DistribDocExpirationUpdateProcessorTest is pretty slow in non nightly test runs.
[ https://issues.apache.org/jira/browse/SOLR-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-6416: -- Issue Type: Sub-task (was: Test) Parent: SOLR-6293 DistribDocExpirationUpdateProcessorTest is pretty slow in non nightly test runs. Key: SOLR-6416 URL: https://issues.apache.org/jira/browse/SOLR-6416 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6416) DistribDocExpirationUpdateProcessorTest is pretty slow in non nightly test runs.
Mark Miller created SOLR-6416: - Summary: DistribDocExpirationUpdateProcessorTest is pretty slow in non nightly test runs. Key: SOLR-6416 URL: https://issues.apache.org/jira/browse/SOLR-6416 Project: Solr Issue Type: Test Components: Tests Reporter: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
stax-utils?
Hi, the NOTICE file of Solr 4.10.0 (and previous ones) includes: === stax-utils library: https://stax-utils.dev.java.net/ Copyright (c) 2004, Christian Niles, unit12.net Copyright (c) 2004, Sun Microsystems, Inc. Copyright (c) 2006, John Kristian License: The BSD License (http://www.opensource.org/licenses/bsd-license.php) === But we don't have this library anywhere in the lib directory. Also the link is incorrect, the correct one would be - but we don't use any of these libraries: https://java.net/projects/stax-utils/pages/Home In addition: === Includes software from other Apache Software Foundation projects, including, but not limited to: [...] - Apache Geronimo (stax API) === The stax-api.jar is no longer shipped with Solr, because we are on Java 6 already (that bundles STAX APIs in JDK). Can we remove that for future versions? - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6416) DistribDocExpirationUpdateProcessorTest is pretty slow in non nightly test runs.
[ https://issues.apache.org/jira/browse/SOLR-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108444#comment-14108444 ] Mark Miller commented on SOLR-6416: --- It looks like this test spends a very long time waiting while nothing is really happening. Perhaps we can override some settings from the test to make things go faster. DistribDocExpirationUpdateProcessorTest is pretty slow in non nightly test runs. Key: SOLR-6416 URL: https://issues.apache.org/jira/browse/SOLR-6416 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: stax-utils?
On August 24, 2014 at 12:28:35 PM, Uwe Schindler (u...@thetaphi.de) wrote: The stax-api.jar is no longer shipped with Solr, because we are on Java 6 already (that bundles STAX APIs in JDK). Can we remove that for future versions? +1 -- Mark Miller about.me/markrmiller - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5889) AnalyzingInfixSuggester should expose commit()
[ https://issues.apache.org/jira/browse/LUCENE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108446#comment-14108446 ] Shawn Heisey commented on LUCENE-5889: -- There's a precommit failure for missing javadoc on AnalyzingInfixSuggester#commit(), added by the svn commit for this issue. If I add a dummy javadoc to the method, precommit passes. I would fix, but I don't really know what the javadoc should say, and I'd rather not add something that's incorrect or incomplete. AnalyzingInfixSuggester should expose commit() -- Key: LUCENE-5889 URL: https://issues.apache.org/jira/browse/LUCENE-5889 Project: Lucene - Core Issue Type: Improvement Components: modules/spellchecker Reporter: Mike Sokolov Fix For: 5.0, 4.11 Attachments: LUCENE-5889.patch, LUCENE-5889.patch There is no way short of close() for a user of AnalyzingInfixSuggester to cause it to commit() its underlying index: only refresh() is provided. But callers might want to ensure the index is flushed to disk without closing. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6417) OpenCloseCoreStressTest should be much faster on non nightly runs.
Mark Miller created SOLR-6417: - Summary: OpenCloseCoreStressTest should be much faster on non nightly runs. Key: SOLR-6417 URL: https://issues.apache.org/jira/browse/SOLR-6417 Project: Solr Issue Type: Test Components: Tests Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6417) OpenCloseCoreStressTest should be much faster on non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108450#comment-14108450 ] ASF subversion and git services commented on SOLR-6417: --- Commit 1620154 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1620154 ] SOLR-6417: OpenCloseCoreStressTest should be much faster on non nightly runs. OpenCloseCoreStressTest should be much faster on non nightly runs. -- Key: SOLR-6417 URL: https://issues.apache.org/jira/browse/SOLR-6417 Project: Solr Issue Type: Test Components: Tests Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6417) OpenCloseCoreStressTest should be much faster on non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108449#comment-14108449 ] ASF subversion and git services commented on SOLR-6417: --- Commit 1620152 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1620152 ] SOLR-6417: OpenCloseCoreStressTest should be much faster on non nightly runs. OpenCloseCoreStressTest should be much faster on non nightly runs. -- Key: SOLR-6417 URL: https://issues.apache.org/jira/browse/SOLR-6417 Project: Solr Issue Type: Test Components: Tests Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5904) Add MDW.enableVirusScanner / fix windows handling bugs
Robert Muir created LUCENE-5904: --- Summary: Add MDW.enableVirusScanner / fix windows handling bugs Key: LUCENE-5904 URL: https://issues.apache.org/jira/browse/LUCENE-5904 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir IndexWriter has logic to handle the case where it can't delete a file (it puts in a retry list and indexfiledeleter will periodically retry, you can force this retry with deletePendingFiles). But from what I can tell, this logic is incomplete, e.g. its not properly handled during CFS creation, so if a file temporarily can't be deleted things like flush will fail. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5904) Add MDW.enableVirusScanner / fix windows handling bugs
[ https://issues.apache.org/jira/browse/LUCENE-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5904: Attachment: LUCENE-5904.patch Here is a patch that just adds the logic to MDW. Some of the fails are false: e.g. tests directly against IFD or directory (These can just disable the option). But some, e.g. the CFS creation fails, are real. Add MDW.enableVirusScanner / fix windows handling bugs -- Key: LUCENE-5904 URL: https://issues.apache.org/jira/browse/LUCENE-5904 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-5904.patch IndexWriter has logic to handle the case where it can't delete a file (it puts in a retry list and indexfiledeleter will periodically retry, you can force this retry with deletePendingFiles). But from what I can tell, this logic is incomplete, e.g. its not properly handled during CFS creation, so if a file temporarily can't be deleted things like flush will fail. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6411) The leader replacement process should no longer be so strict that only a previously active replica can become leader.
[ https://issues.apache.org/jira/browse/SOLR-6411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-6411: -- Attachment: SOLR-6411.patch The leader replacement process should no longer be so strict that only a previously active replica can become leader. - Key: SOLR-6411 URL: https://issues.apache.org/jira/browse/SOLR-6411 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Attachments: SOLR-6411.patch, SOLR-6411.patch, SOLR-6411.patch, SOLR-6411.patch, SOLR-6411.patch -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: stax-utils?
Hi, I just wanted to be sure, that stax-utils is not used (maybe due to a code fork). In any case, I will now remove the 2 items from NOTICE. If we respin 4.10, we should remove that from there, too. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Mark Miller [mailto:markrmil...@gmail.com] Sent: Sunday, August 24, 2014 6:31 PM To: dev@lucene.apache.org Subject: Re: stax-utils? On August 24, 2014 at 12:28:35 PM, Uwe Schindler (u...@thetaphi.de) wrote: The stax-api.jar is no longer shipped with Solr, because we are on Java 6 already (that bundles STAX APIs in JDK). Can we remove that for future versions? +1 -- Mark Miller about.me/markrmiller - 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
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 1788 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1788/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.schema.TestCloudSchemaless.testDistribSearch Error Message: Timeout occured while waiting response from server at: https://127.0.0.1:49503/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: https://127.0.0.1:49503/collection1 at __randomizedtesting.SeedInfo.seed([75C393836DC27B71:F4251D9B1A9D1B4D]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:558) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:210) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:206) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:124) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:68) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:54) at org.apache.solr.schema.TestCloudSchemaless.doTest(TestCloudSchemaless.java:140) 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
[jira] [Created] (SOLR-6418) ChaosMonkeySafeLeaderTest is to slow on non nightly runs sometimes.
Mark Miller created SOLR-6418: - Summary: ChaosMonkeySafeLeaderTest is to slow on non nightly runs sometimes. Key: SOLR-6418 URL: https://issues.apache.org/jira/browse/SOLR-6418 Project: Solr Issue Type: Test Reporter: Mark Miller This test should use runtimes based on nightly the same way that ChaosMonkeyNothingIsSafeTest does. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6418) ChaosMonkeySafeLeaderTest is to slow on non nightly runs sometimes.
[ https://issues.apache.org/jira/browse/SOLR-6418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-6418: -- Issue Type: Sub-task (was: Test) Parent: SOLR-6293 ChaosMonkeySafeLeaderTest is to slow on non nightly runs sometimes. --- Key: SOLR-6418 URL: https://issues.apache.org/jira/browse/SOLR-6418 Project: Solr Issue Type: Sub-task Reporter: Mark Miller This test should use runtimes based on nightly the same way that ChaosMonkeyNothingIsSafeTest does. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6418) ChaosMonkeySafeLeaderTest is to slow on non nightly runs sometimes.
[ https://issues.apache.org/jira/browse/SOLR-6418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108459#comment-14108459 ] ASF subversion and git services commented on SOLR-6418: --- Commit 1620162 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1620162 ] SOLR-6418: ChaosMonkeySafeLeaderTest is to slow on non nightly runs sometimes. ChaosMonkeySafeLeaderTest is to slow on non nightly runs sometimes. --- Key: SOLR-6418 URL: https://issues.apache.org/jira/browse/SOLR-6418 Project: Solr Issue Type: Sub-task Reporter: Mark Miller This test should use runtimes based on nightly the same way that ChaosMonkeyNothingIsSafeTest does. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6419) The ChaosMonkey tests should use fewers jetty instances on non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-6419: -- Issue Type: Sub-task (was: Test) Parent: SOLR-6293 The ChaosMonkey tests should use fewers jetty instances on non nightly runs. Key: SOLR-6419 URL: https://issues.apache.org/jira/browse/SOLR-6419 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6419) The ChaosMonkey tests should use fewers jetty instances on non nightly runs.
Mark Miller created SOLR-6419: - Summary: The ChaosMonkey tests should use fewers jetty instances on non nightly runs. Key: SOLR-6419 URL: https://issues.apache.org/jira/browse/SOLR-6419 Project: Solr Issue Type: Test Components: Tests Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-6418) ChaosMonkeySafeLeaderTest is too slow on non nightly runs sometimes.
[ https://issues.apache.org/jira/browse/SOLR-6418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-6418: - Assignee: Mark Miller ChaosMonkeySafeLeaderTest is too slow on non nightly runs sometimes. Key: SOLR-6418 URL: https://issues.apache.org/jira/browse/SOLR-6418 Project: Solr Issue Type: Sub-task Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.11 This test should use runtimes based on nightly the same way that ChaosMonkeyNothingIsSafeTest does. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6418) ChaosMonkeySafeLeaderTest is too slow on non nightly runs sometimes.
[ https://issues.apache.org/jira/browse/SOLR-6418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108462#comment-14108462 ] ASF subversion and git services commented on SOLR-6418: --- Commit 1620164 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1620164 ] SOLR-6418: ChaosMonkeySafeLeaderTest is too slow on non nightly runs sometimes. ChaosMonkeySafeLeaderTest is too slow on non nightly runs sometimes. Key: SOLR-6418 URL: https://issues.apache.org/jira/browse/SOLR-6418 Project: Solr Issue Type: Sub-task Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.11 This test should use runtimes based on nightly the same way that ChaosMonkeyNothingIsSafeTest does. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6418) ChaosMonkeySafeLeaderTest is too slow on non nightly runs sometimes.
[ https://issues.apache.org/jira/browse/SOLR-6418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-6418. --- Resolution: Fixed Fix Version/s: 4.11 5.0 ChaosMonkeySafeLeaderTest is too slow on non nightly runs sometimes. Key: SOLR-6418 URL: https://issues.apache.org/jira/browse/SOLR-6418 Project: Solr Issue Type: Sub-task Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.11 This test should use runtimes based on nightly the same way that ChaosMonkeyNothingIsSafeTest does. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6418) ChaosMonkeySafeLeaderTest is too slow on non nightly runs sometimes.
[ https://issues.apache.org/jira/browse/SOLR-6418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-6418: -- Summary: ChaosMonkeySafeLeaderTest is too slow on non nightly runs sometimes. (was: ChaosMonkeySafeLeaderTest is to slow on non nightly runs sometimes.) ChaosMonkeySafeLeaderTest is too slow on non nightly runs sometimes. Key: SOLR-6418 URL: https://issues.apache.org/jira/browse/SOLR-6418 Project: Solr Issue Type: Sub-task Reporter: Mark Miller Fix For: 5.0, 4.11 This test should use runtimes based on nightly the same way that ChaosMonkeyNothingIsSafeTest does. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6403) TransactionLog replay status logging.
[ https://issues.apache.org/jira/browse/SOLR-6403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108465#comment-14108465 ] ASF subversion and git services commented on SOLR-6403: --- Commit 1620166 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1620166 ] SOLR-6403: TransactionLog replay status logging. TransactionLog replay status logging. - Key: SOLR-6403 URL: https://issues.apache.org/jira/browse/SOLR-6403 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.11 Attachments: SOLR-6403.patch You are pretty much in the dark currently when transaction logs are replaying. We should periodically log progress. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6293) Solr tests have gotten much slower.
[
https://issues.apache.org/jira/browse/SOLR-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108466#comment-14108466
]
Mark Miller commented on SOLR-6293:
---
I've knocked a few of the slowest tests off the list. Here is the current
accounting:
{noformat}
[junit4:tophints] 257.56s | org.apache.solr.handler.TestReplicationHandler
[junit4:tophints] 112.90s | org.apache.solr.cloud.BasicDistributedZkTest
[junit4:tophints] 112.90s |
org.apache.solr.cloud.CollectionsAPIDistributedZkTest
[junit4:tophints] 104.33s | org.apache.solr.cloud.ShardSplitTest
[junit4:tophints] 92.20s |
org.apache.solr.schema.TestCloudManagedSchemaConcurrent
{noformat}
Solr tests have gotten much slower.
---
Key: SOLR-6293
URL: https://issues.apache.org/jira/browse/SOLR-6293
Project: Solr
Issue Type: Test
Reporter: Mark Miller
Assignee: Mark Miller
I run tests with 8 jvms before I took a 2-3 month hiatus from Lucene / Solr,
Solr tests ran in about 9-10 minutes on my machine. Now it's 16 minutes. This
issue is a top level issue to track looking into what has caused the
additional time, if it makes sense, or if there is stuff we can move to
nightly.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6419) The ChaosMonkey tests should use fewers jetty instances on non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108468#comment-14108468 ] ASF subversion and git services commented on SOLR-6419: --- Commit 1620167 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1620167 ] SOLR-6419: The ChaosMonkey tests should use fewers jetty instances on non nightly runs. The ChaosMonkey tests should use fewers jetty instances on non nightly runs. Key: SOLR-6419 URL: https://issues.apache.org/jira/browse/SOLR-6419 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6420) ADDREPLICA can add a replica that reports green without actually replicating
Ralph Tice created SOLR-6420: Summary: ADDREPLICA can add a replica that reports green without actually replicating Key: SOLR-6420 URL: https://issues.apache.org/jira/browse/SOLR-6420 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10 Environment: Ubuntu 14.04 Reporter: Ralph Tice Priority: Critical I am running Solr built off branch_4x, and thanks to some help from IRC ([~hossman_luc...@fucit.org]) we've determined that we have an incompatible index situation where we have indexes built with 4.9 that we can read but not index into further or update. In this situation, if I try to add a replica, this also fails, however, the only log ouput (at WARN threshold) is: 16:21:58.156 [RecoveryThread] WARN org.apache.solr.update.PeerSync - no frame of reference to tell if we've missed updates ...and the replica comes up green. I think this might indicate a missing integrity check on replication but certainly IMO a replica should report as green/active if it is not on the same revision as the leader, or at least if it has never been on the same revision as the leader. Shards built with the currently running version of Solr are able to successfully ADDREPLICA as expected. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6403) TransactionLog replay status logging.
[ https://issues.apache.org/jira/browse/SOLR-6403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108469#comment-14108469 ] ASF subversion and git services commented on SOLR-6403: --- Commit 1620168 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1620168 ] SOLR-6403: TransactionLog replay status logging. TransactionLog replay status logging. - Key: SOLR-6403 URL: https://issues.apache.org/jira/browse/SOLR-6403 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.11 Attachments: SOLR-6403.patch You are pretty much in the dark currently when transaction logs are replaying. We should periodically log progress. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6421) ADDREPLICA doesn't respect :port_solr designation
Ralph Tice created SOLR-6421: Summary: ADDREPLICA doesn't respect :port_solr designation Key: SOLR-6421 URL: https://issues.apache.org/jira/browse/SOLR-6421 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10 Environment: Ubuntu 14.04 Reporter: Ralph Tice When I issue an ADDREPLICA call like so: http://localhost:8983/solr/admin/collections?action=ADDREPLICAshard=myshardcollection=mycollectioncreateNodeSet=solr18.mycorp.com:8983_solr SolrCloud does not seem to respect the 8983_solr designation in the createNodeSet parameter and instead places the shard on any JVM on the machine instance. First attempt I got a replica on 8994_solr and second attempt to place a replica on 8983 got a replica on 8992_solr instead. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6417) OpenCloseCoreStressTest should be much faster on non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-6417. --- Resolution: Fixed Fix Version/s: 4.11 5.0 OpenCloseCoreStressTest should be much faster on non nightly runs. -- Key: SOLR-6417 URL: https://issues.apache.org/jira/browse/SOLR-6417 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.11 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6417) OpenCloseCoreStressTest should be much faster on non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-6417: -- Issue Type: Sub-task (was: Test) Parent: SOLR-6293 OpenCloseCoreStressTest should be much faster on non nightly runs. -- Key: SOLR-6417 URL: https://issues.apache.org/jira/browse/SOLR-6417 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.11 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5904) Add MDW.enableVirusScanner / fix windows handling bugs
[
https://issues.apache.org/jira/browse/LUCENE-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-5904:
Attachment: LUCENE-5904.patch
Patch fixing 3 bugs so far (Lucene40SIWriter, Lucene46SIWriter,
CompoundFileWriter). There might be more bugs: we should review all uses of
Directory.deleteFile to make sure we are doing the right thing.
I also fixed up core tests that currently rely upon e.g. unref'ed files check
or manipulate files directly to disable the option.
I may have made a mistake or unconvered something in disk full test that i
havent investigated yet:
{noformat}
[junit4] Suite: org.apache.lucene.index.TestIndexWriterOnDiskFull
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestIndexWriterOnDiskFull -Dtests.method=testImmediateDiskFull
-Dtests.seed=2D75D397EE0B3214 -Dtests.locale=ga_IE
-Dtests.timezone=Europe/Lisbon -Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 0.20s | TestIndexWriterOnDiskFull.testImmediateDiskFull
[junit4] Throwable #1: java.io.EOFException: read past EOF:
RAMInputStream(name=segments_1)
[junit4]at
__randomizedtesting.SeedInfo.seed([2D75D397EE0B3214:BC3341FB920ADCD0]:0)
[junit4]at
org.apache.lucene.store.RAMInputStream.switchCurrentBuffer(RAMInputStream.java:98)
[junit4]at
org.apache.lucene.store.RAMInputStream.readByte(RAMInputStream.java:71)
[junit4]at
org.apache.lucene.store.MockIndexInputWrapper.readByte(MockIndexInputWrapper.java:122)
[junit4]at
org.apache.lucene.store.BufferedChecksumIndexInput.readByte(BufferedChecksumIndexInput.java:41)
[junit4]at
org.apache.lucene.store.DataInput.readInt(DataInput.java:98)
[junit4]at
org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:356)
[junit4]at
org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:463)
[junit4]at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:804)
[junit4]at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:650)
[junit4]at
org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:459)
[junit4]at
org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:398)
[junit4]at
org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:207)
[junit4]at
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:711)
[junit4]at
org.apache.lucene.index.TestIndexWriterOnDiskFull.testImmediateDiskFull(TestIndexWriterOnDiskFull.java:569)
[junit4]at java.lang.Thread.run(Thread.java:745)
{noformat}
Maybe something isn't quite right in the windows handlign there?
Add MDW.enableVirusScanner / fix windows handling bugs
--
Key: LUCENE-5904
URL: https://issues.apache.org/jira/browse/LUCENE-5904
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Attachments: LUCENE-5904.patch, LUCENE-5904.patch
IndexWriter has logic to handle the case where it can't delete a file (it
puts in a retry list and indexfiledeleter will periodically retry, you can
force this retry with deletePendingFiles).
But from what I can tell, this logic is incomplete, e.g. its not properly
handled during CFS creation, so if a file temporarily can't be deleted things
like flush will fail.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6419) The ChaosMonkey tests should use fewers jetty instances on non nightly runs.
[ https://issues.apache.org/jira/browse/SOLR-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108474#comment-14108474 ] ASF subversion and git services commented on SOLR-6419: --- Commit 1620170 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1620170 ] SOLR-6419: The ChaosMonkey tests should use fewers jetty instances on non nightly runs. The ChaosMonkey tests should use fewers jetty instances on non nightly runs. Key: SOLR-6419 URL: https://issues.apache.org/jira/browse/SOLR-6419 Project: Solr Issue Type: Sub-task Components: Tests Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5904) Add MDW.enableVirusScanner / fix windows handling bugs
[ https://issues.apache.org/jira/browse/LUCENE-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108476#comment-14108476 ] Uwe Schindler commented on LUCENE-5904: --- I like the virus scanner, just doing nothing - only holding files open :-) I wish all virus scanner would do nothing! Add MDW.enableVirusScanner / fix windows handling bugs -- Key: LUCENE-5904 URL: https://issues.apache.org/jira/browse/LUCENE-5904 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-5904.patch, LUCENE-5904.patch IndexWriter has logic to handle the case where it can't delete a file (it puts in a retry list and indexfiledeleter will periodically retry, you can force this retry with deletePendingFiles). But from what I can tell, this logic is incomplete, e.g. its not properly handled during CFS creation, so if a file temporarily can't be deleted things like flush will fail. -- This message was sent by Atlassian JIRA (v6.2#6252) - 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.7.0_67) - Build # 11095 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11095/ Java: 64bit/jdk1.7.0_67 -XX:-UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 46504 lines...] -documentation-lint: [echo] checking for broken html... [jtidy] Checking for broken html (such as invalid tags)... [delete] Deleting directory /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/jtidy_tmp [echo] Checking for broken links... [exec] [exec] Crawl/parse... [exec] [exec] Verify... [echo] Checking for missing docs... [exec] [exec] build/docs/suggest/org/apache/lucene/search/suggest/analyzing/AnalyzingInfixSuggester.html [exec] missing Methods: commit() [exec] [exec] Missing javadocs were found! BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:485: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:66: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:212: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:257: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:2419: exec returned: 1 Total time: 99 minutes 12 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.7.0_67 -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] [Created] (SOLR-6422) DELETEREPLICA exposes an inconsistent param REPLICA_PROP
Ralph Tice created SOLR-6422: Summary: DELETEREPLICA exposes an inconsistent param REPLICA_PROP Key: SOLR-6422 URL: https://issues.apache.org/jira/browse/SOLR-6422 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10 Environment: Ubuntu 14.04 Reporter: Ralph Tice Priority: Minor DELETEREPLICA asks for the ZK shard id (core_node_###) instead of the same syntax as createNodeSet? I can't recall any other instance in which the ZK shard id is exposed via query parameter and I've only ever seen it in clusterstate.json / CLUSTERSTATUS calls. For ease of use I humbly suggest that the API be amended to take the same parameters are ADDREPLICA and use either base_url or core_node_name. Specifically, instead of REPLICA_PROP here https://github.com/apache/lucene-solr/blob/branch_4x/solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L64 it would be more consistent to request a query param of the form: https://github.com/apache/lucene-solr/blob/branch_4x/solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L58 or: https://github.com/apache/lucene-solr/blob/branch_4x/solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L56 Also it appears DELETEREPLICA is missing from https://github.com/apache/lucene-solr/blob/branch_4x/solr/solrj/src/java/org/apache/solr/common/params/CollectionParams.java -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6422) DELETEREPLICA exposes an inconsistent param REPLICA_PROP
[ https://issues.apache.org/jira/browse/SOLR-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108480#comment-14108480 ] Ralph Tice commented on SOLR-6422: -- Linking original Jira for historical reference, didn't seem to get much dialogue at that time. DELETEREPLICA exposes an inconsistent param REPLICA_PROP Key: SOLR-6422 URL: https://issues.apache.org/jira/browse/SOLR-6422 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10 Environment: Ubuntu 14.04 Reporter: Ralph Tice Priority: Minor DELETEREPLICA asks for the ZK shard id (core_node_###) instead of the same syntax as createNodeSet? I can't recall any other instance in which the ZK shard id is exposed via query parameter and I've only ever seen it in clusterstate.json / CLUSTERSTATUS calls. For ease of use I humbly suggest that the API be amended to take the same parameters are ADDREPLICA and use either base_url or core_node_name. Specifically, instead of REPLICA_PROP here https://github.com/apache/lucene-solr/blob/branch_4x/solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L64 it would be more consistent to request a query param of the form: https://github.com/apache/lucene-solr/blob/branch_4x/solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L58 or: https://github.com/apache/lucene-solr/blob/branch_4x/solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L56 Also it appears DELETEREPLICA is missing from https://github.com/apache/lucene-solr/blob/branch_4x/solr/solrj/src/java/org/apache/solr/common/params/CollectionParams.java -- This message was sent by Atlassian JIRA (v6.2#6252) - 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 # 610 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/610/ All tests passed Build Log: [...truncated 46945 lines...] -documentation-lint: [echo] checking for broken html... [jtidy] Checking for broken html (such as invalid tags)... [delete] Deleting directory /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/lucene/build/jtidy_tmp [echo] Checking for broken links... [exec] [exec] Crawl/parse... [exec] [exec] Verify... [echo] Checking for missing docs... [exec] [exec] build/docs/suggest/org/apache/lucene/search/suggest/analyzing/AnalyzingInfixSuggester.html [exec] missing Methods: commit() [exec] [exec] Missing javadocs were found! BUILD FAILED /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/build.xml:492: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/build.xml:66: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/lucene/build.xml:212: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/lucene/build.xml:257: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/lucene/common-build.xml:2419: exec returned: 1 Total time: 255 minutes 59 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Sending artifact delta relative to Lucene-Solr-NightlyTests-trunk #605 Archived 1 artifacts Archive block size is 32768 Received 0 blocks and 464 bytes Compression is 0.0% Took 22 ms Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5776) Look at speeding up using SSL with tests.
[
https://issues.apache.org/jira/browse/SOLR-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108495#comment-14108495
]
Steve Rowe commented on SOLR-5776:
--
bq. I re-enabled SSL on TestCloudSchemaless, and I'll monitor Jenkins to see if
it starts failing.
It's definitely started failing.
AFAICT, the experiment to feed the entropy pool using a regularly-run cron job
to write to {{/dev/random}} has failed: {{TestCloudSchemaless}} fails regularly
on the two VMs I set up the cron job (ASF FreeBSD and Policeman OS X).
I'll go disable SSL for this test now.
Look at speeding up using SSL with tests.
-
Key: SOLR-5776
URL: https://issues.apache.org/jira/browse/SOLR-5776
Project: Solr
Issue Type: Test
Reporter: Mark Miller
Assignee: Mark Miller
Fix For: 4.9, 5.0
Attachments: SOLR-5776.patch, SOLR-5776.patch
We have to disable SSL on a bunch of tests now because it appears to sometime
be ridiculously slow - especially in slow envs (I never see timeouts on my
machine).
I was talking to Robert about this, and he mentioned that there might be some
settings we could change to speed it up.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5776) Look at speeding up using SSL with tests.
[ https://issues.apache.org/jira/browse/SOLR-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108498#comment-14108498 ] ASF subversion and git services commented on SOLR-5776: --- Commit 1620176 from [~sar...@syr.edu] in branch 'dev/trunk' [ https://svn.apache.org/r1620176 ] SOLR-5776: suppress ssl for this test Look at speeding up using SSL with tests. - Key: SOLR-5776 URL: https://issues.apache.org/jira/browse/SOLR-5776 Project: Solr Issue Type: Test Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.9, 5.0 Attachments: SOLR-5776.patch, SOLR-5776.patch We have to disable SSL on a bunch of tests now because it appears to sometime be ridiculously slow - especially in slow envs (I never see timeouts on my machine). I was talking to Robert about this, and he mentioned that there might be some settings we could change to speed it up. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6024) StatsComponent does not work for docValues enabled multiValued fields
[
https://issues.apache.org/jira/browse/SOLR-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6024:
---
Attachment: SOLR-6024.patch
Added patch based for lucene_solr_4_9 branch fixing issue,
for fields having docValues called
org.apache.solr.request.DocValuesStats#getCounts from rev. 1595259 and
UnInvertedField in other cases.
StatsComponent does not work for docValues enabled multiValued fields
-
Key: SOLR-6024
URL: https://issues.apache.org/jira/browse/SOLR-6024
Project: Solr
Issue Type: Bug
Components: SearchComponents - other
Affects Versions: 4.8
Environment: java version 1.7.0_45
Mac OS X Version 10.7.5
Reporter: Ahmet Arslan
Labels: StatsComponent, docValues, multiValued
Fix For: 4.9
Attachments: SOLR-6024.patch, SOLR-6024.patch
Harish Agarwal reported this in solr user mailing list :
http://search-lucene.com/m/QTPaoTJXV1
It is east to re-produce with default example solr setup. Following types are
added example schema.xml. And exampledocs are indexed.
{code:xml}
field name=cat type=string indexed=true stored=true
docValues=true multiValued=true/
field name=popularity type=int indexed=true stored=false
docValues=true multiValued=true/
{code}
When {{docValues=true}} *and* {{multiValued=true}} are used at the same
time, StatsComponent throws :
{noformat}
ERROR org.apache.solr.core.SolrCore – org.apache.solr.common.SolrException:
Type mismatch: popularity was indexed as SORTED_SET
at
org.apache.solr.request.UnInvertedField.init(UnInvertedField.java:193)
at
org.apache.solr.request.UnInvertedField.getUnInvertedField(UnInvertedField.java:699)
at
org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:319)
at
org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:290)
at
org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:78)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:221)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1964)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5776) Look at speeding up using SSL with tests.
[ https://issues.apache.org/jira/browse/SOLR-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108501#comment-14108501 ] ASF subversion and git services commented on SOLR-5776: --- Commit 1620177 from [~sar...@syr.edu] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1620177 ] SOLR-5776: suppress ssl for this test (merged trunk r1620176) Look at speeding up using SSL with tests. - Key: SOLR-5776 URL: https://issues.apache.org/jira/browse/SOLR-5776 Project: Solr Issue Type: Test Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.9, 5.0 Attachments: SOLR-5776.patch, SOLR-5776.patch We have to disable SSL on a bunch of tests now because it appears to sometime be ridiculously slow - especially in slow envs (I never see timeouts on my machine). I was talking to Robert about this, and he mentioned that there might be some settings we could change to speed it up. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.8.0) - Build # 1750 - Still Failing!
I uncommented the @SuppressSSL annotation on this test - see SOLR-5776. Steve On Aug 23, 2014, at 5:16 PM, Uwe Schindler u...@thetaphi.de wrote: Hi, this test fails all the time on any operating system. Please fix or disable it! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de] Sent: Saturday, August 23, 2014 11:11 PM To: rjer...@apache.org; jbern...@apache.org; dev@lucene.apache.org Subject: [JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.8.0) - Build # 1750 - Still Failing! Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1750/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.schema.TestCloudSchemaless.testDistribSearch Error Message: Timeout occured while waiting response from server at: https://127.0.0.1:56511/n/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: https://127.0.0.1:56511/n/collection1 at __randomizedtesting.SeedInfo.seed([83AF82324C594018:2490C2A3B062024] :0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrSer ver.java:560) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java: 210) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java: 206) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(Abstrac tUpdateRequest.java:124) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:68) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:54) at org.apache.solr.schema.TestCloudSchemaless.doTest(TestCloudSchemaless. java:140) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistri butedSearchTestCase.java:871) at sun.reflect.GeneratedMethodAccessor47.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize dRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando mizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando mizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando mizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1. evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule SetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCa cheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA fterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1 .evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh readAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule IgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure .java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat ementAdapter.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(ThreadL eakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran domizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(Rando mizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(Rando mizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando mizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat ementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1. evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA fterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCl assName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1 .evaluate(SystemPropertiesInvariantRule.java:55) at
RE: [JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.8.0) - Build # 1750 - Still Failing!
Thanks Steve, I was not aware, that you already took care of this test! About the cron experiment: - MacOSX was reverted to VM snapshot, so the crontab was disabled - FreeBSD: The user name was changed Hudson - Jenkins, so I think the crontab got lost, too. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Steve Rowe [mailto:sar...@gmail.com] Sent: Sunday, August 24, 2014 9:16 PM To: dev@lucene.apache.org Subject: Re: [JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.8.0) - Build # 1750 - Still Failing! I uncommented the @SuppressSSL annotation on this test - see SOLR-5776. Steve On Aug 23, 2014, at 5:16 PM, Uwe Schindler u...@thetaphi.de wrote: Hi, this test fails all the time on any operating system. Please fix or disable it! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de] Sent: Saturday, August 23, 2014 11:11 PM To: rjer...@apache.org; jbern...@apache.org; dev@lucene.apache.org Subject: [JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.8.0) - Build # 1750 - Still Failing! Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1750/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.schema.TestCloudSchemaless.testDistribSearch Error Message: Timeout occured while waiting response from server at: https://127.0.0.1:56511/n/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: https://127.0.0.1:56511/n/collection1 at __randomizedtesting.SeedInfo.seed([83AF82324C594018:2490C2A3B062024] :0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrSer ver.java:560) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java: 210) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java: 206) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(Abstrac tUpdateRequest.java:124) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:68) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:54) at org.apache.solr.schema.TestCloudSchemaless.doTest(TestCloudSchemaless. java:140) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistri butedSearchTestCase.java:871) at sun.reflect.GeneratedMethodAccessor47.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize dRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando mizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando mizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando mizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1. evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule SetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCa cheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA fterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1 .evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh readAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule IgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure .java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat ementAdapter.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(ThreadL eakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran domizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(Rando mizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(Rando mizedRunner.java:772) at
[jira] [Commented] (SOLR-5776) Look at speeding up using SSL with tests.
[ https://issues.apache.org/jira/browse/SOLR-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108507#comment-14108507 ] Uwe Schindler commented on SOLR-5776: - bq. AFAICT, the experiment to feed the entropy pool using a regularly-run cron job to write to /dev/random has failed: TestCloudSchemaless fails regularly on the two VMs I set up the cron job (ASF FreeBSD and Policeman OS X). I think the crons are already disabled: - MacOSX was reverted to VM snapshot, so the crontab was disabled - FreeBSD: The user name was changed Hudson - Jenkins, so I think the crontab got lost, too. Look at speeding up using SSL with tests. - Key: SOLR-5776 URL: https://issues.apache.org/jira/browse/SOLR-5776 Project: Solr Issue Type: Test Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.9, 5.0 Attachments: SOLR-5776.patch, SOLR-5776.patch We have to disable SSL on a bunch of tests now because it appears to sometime be ridiculously slow - especially in slow envs (I never see timeouts on my machine). I was talking to Robert about this, and he mentioned that there might be some settings we could change to speed it up. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5889) AnalyzingInfixSuggester should expose commit()
[ https://issues.apache.org/jira/browse/LUCENE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108512#comment-14108512 ] Michael McCandless commented on LUCENE-5889: Grr, sorry for all the noise here :( I'll fix the javadocs smoke test failure. AnalyzingInfixSuggester should expose commit() -- Key: LUCENE-5889 URL: https://issues.apache.org/jira/browse/LUCENE-5889 Project: Lucene - Core Issue Type: Improvement Components: modules/spellchecker Reporter: Mike Sokolov Fix For: 5.0, 4.11 Attachments: LUCENE-5889.patch, LUCENE-5889.patch There is no way short of close() for a user of AnalyzingInfixSuggester to cause it to commit() its underlying index: only refresh() is provided. But callers might want to ensure the index is flushed to disk without closing. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6423) HdfsCollectionsAPIDistributedZkTest test fail: Could not find new collection awholynewcollection_1
Mark Miller created SOLR-6423:
-
Summary: HdfsCollectionsAPIDistributedZkTest test fail: Could not
find new collection awholynewcollection_1
Key: SOLR-6423
URL: https://issues.apache.org/jira/browse/SOLR-6423
Project: Solr
Issue Type: Test
Components: hdfs
Reporter: Mark Miller
Assignee: Mark Miller
{noformat}
java.lang.AssertionError: Could not find new collection awholynewcollection_1
at
__randomizedtesting.SeedInfo.seed([655D020D02309D33:E4BB8C15756FFD0F]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkForCollection(AbstractFullDistribZkTestBase.java:1642)
at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:723)
at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.7.0_67) - Build # 10966 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/10966/ Java: 64bit/jdk1.7.0_67 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 32639 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-4.x-Linux/lucene/tools/forbiddenApis/base.txt [forbidden-apis] Reading API signatures: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-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.text.DecimalFormat#init(java.lang.String) [Uses default locale] [forbidden-apis] in org.apache.solr.update.UpdateLog$LogReplayer (UpdateLog.java:1272) [forbidden-apis] Scanned (and 1523 related) class file(s) for forbidden API invocations (in 1.88s), 1 error(s). BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:485: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:73: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build.xml:271: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/common-build.xml:477: Check for forbidden API calls failed, see log. Total time: 96 minutes 26 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.7.0_67 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 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] [Updated] (SOLR-5666) Using the hdfs write cache can result in appearance of corrupted index.
[ https://issues.apache.org/jira/browse/SOLR-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5666: -- Fix Version/s: (was: 4.9) 4.7 Using the hdfs write cache can result in appearance of corrupted index. --- Key: SOLR-5666 URL: https://issues.apache.org/jira/browse/SOLR-5666 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.7, 5.0 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5666) Using the hdfs write cache can result in appearance of corrupted index.
[ https://issues.apache.org/jira/browse/SOLR-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-5666. --- Resolution: Fixed Using the hdfs write cache can result in appearance of corrupted index. --- Key: SOLR-5666 URL: https://issues.apache.org/jira/browse/SOLR-5666 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-5907) The hdfs write cache can still cause a reader to see a corrupted state.
[ https://issues.apache.org/jira/browse/SOLR-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reopened SOLR-5907: --- The hdfs write cache can still cause a reader to see a corrupted state. --- Key: SOLR-5907 URL: https://issues.apache.org/jira/browse/SOLR-5907 Project: Solr Issue Type: Bug Components: hdfs Reporter: Mark Miller Assignee: Mark Miller Priority: Critical Fix For: 4.7.1, 4.8, 5.0 Attachments: SOLR-5907.patch, SOLR-5907.patch We should disable it by default and probably take it out of the default configs until we can track down the issues with it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5889) AnalyzingInfixSuggester should expose commit()
[ https://issues.apache.org/jira/browse/LUCENE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108518#comment-14108518 ] ASF subversion and git services commented on LUCENE-5889: - Commit 1620180 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1620180 ] LUCENE-5889: add missing javadocs AnalyzingInfixSuggester should expose commit() -- Key: LUCENE-5889 URL: https://issues.apache.org/jira/browse/LUCENE-5889 Project: Lucene - Core Issue Type: Improvement Components: modules/spellchecker Reporter: Mike Sokolov Fix For: 5.0, 4.11 Attachments: LUCENE-5889.patch, LUCENE-5889.patch There is no way short of close() for a user of AnalyzingInfixSuggester to cause it to commit() its underlying index: only refresh() is provided. But callers might want to ensure the index is flushed to disk without closing. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5907) The hdfs write cache can still cause a reader to see a corrupted state.
[ https://issues.apache.org/jira/browse/SOLR-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108517#comment-14108517 ] Mark Miller commented on SOLR-5907: --- What I committed didn't match the last patch somehow - it is missing: +boolean blockCacheWriteEnabled = params.getBool(BLOCKCACHE_WRITE_ENABLED, false); The hdfs write cache can still cause a reader to see a corrupted state. --- Key: SOLR-5907 URL: https://issues.apache.org/jira/browse/SOLR-5907 Project: Solr Issue Type: Bug Components: hdfs Reporter: Mark Miller Assignee: Mark Miller Priority: Critical Fix For: 4.7.1, 4.8, 5.0 Attachments: SOLR-5907.patch, SOLR-5907.patch We should disable it by default and probably take it out of the default configs until we can track down the issues with it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5907) The hdfs write cache can still cause a reader to see a corrupted state.
[ https://issues.apache.org/jira/browse/SOLR-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-5907. --- Resolution: Done The hdfs write cache can still cause a reader to see a corrupted state. --- Key: SOLR-5907 URL: https://issues.apache.org/jira/browse/SOLR-5907 Project: Solr Issue Type: Bug Components: hdfs Reporter: Mark Miller Assignee: Mark Miller Priority: Critical Fix For: 5.0, 4.8, 4.7.1 Attachments: SOLR-5907.patch, SOLR-5907.patch We should disable it by default and probably take it out of the default configs until we can track down the issues with it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6424) The hdfs block cache BLOCKCACHE_WRITE_ENABLED is not defaulting to false like it should.
Mark Miller created SOLR-6424: - Summary: The hdfs block cache BLOCKCACHE_WRITE_ENABLED is not defaulting to false like it should. Key: SOLR-6424 URL: https://issues.apache.org/jira/browse/SOLR-6424 Project: Solr Issue Type: Bug Components: hdfs Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.11 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5907) The hdfs write cache can still cause a reader to see a corrupted state.
[ https://issues.apache.org/jira/browse/SOLR-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108520#comment-14108520 ] Mark Miller commented on SOLR-5907: --- I filed: SOLR-6424 The hdfs block cache BLOCKCACHE_WRITE_ENABLED is not defaulting to false like it should. The hdfs write cache can still cause a reader to see a corrupted state. --- Key: SOLR-5907 URL: https://issues.apache.org/jira/browse/SOLR-5907 Project: Solr Issue Type: Bug Components: hdfs Reporter: Mark Miller Assignee: Mark Miller Priority: Critical Fix For: 4.7.1, 4.8, 5.0 Attachments: SOLR-5907.patch, SOLR-5907.patch We should disable it by default and probably take it out of the default configs until we can track down the issues with it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5904) Add MDW.enableVirusScanner / fix windows handling bugs
[ https://issues.apache.org/jira/browse/LUCENE-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108521#comment-14108521 ] Michael McCandless commented on LUCENE-5904: +1, this is a nice new evilness for MDW! But that EOFE is terrifying? Add MDW.enableVirusScanner / fix windows handling bugs -- Key: LUCENE-5904 URL: https://issues.apache.org/jira/browse/LUCENE-5904 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-5904.patch, LUCENE-5904.patch IndexWriter has logic to handle the case where it can't delete a file (it puts in a retry list and indexfiledeleter will periodically retry, you can force this retry with deletePendingFiles). But from what I can tell, this logic is incomplete, e.g. its not properly handled during CFS creation, so if a file temporarily can't be deleted things like flush will fail. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5889) AnalyzingInfixSuggester should expose commit()
[ https://issues.apache.org/jira/browse/LUCENE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108524#comment-14108524 ] ASF subversion and git services commented on LUCENE-5889: - Commit 1620182 from [~mikemccand] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1620182 ] LUCENE-5889: add missing javadocs AnalyzingInfixSuggester should expose commit() -- Key: LUCENE-5889 URL: https://issues.apache.org/jira/browse/LUCENE-5889 Project: Lucene - Core Issue Type: Improvement Components: modules/spellchecker Reporter: Mike Sokolov Fix For: 5.0, 4.11 Attachments: LUCENE-5889.patch, LUCENE-5889.patch There is no way short of close() for a user of AnalyzingInfixSuggester to cause it to commit() its underlying index: only refresh() is provided. But callers might want to ensure the index is flushed to disk without closing. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6423) HdfsCollectionsAPIDistributedZkTest test fail: Could not find new collection awholynewcollection_1
[
https://issues.apache.org/jira/browse/SOLR-6423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108523#comment-14108523
]
ASF subversion and git services commented on SOLR-6423:
---
Commit 1620181 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1620181 ]
SOLR-6424: The hdfs block cache BLOCKCACHE_WRITE_ENABLED is not defaulting to
false like it should.
May be related to the SOLR-6423 fail.
HdfsCollectionsAPIDistributedZkTest test fail: Could not find new collection
awholynewcollection_1
--
Key: SOLR-6423
URL: https://issues.apache.org/jira/browse/SOLR-6423
Project: Solr
Issue Type: Test
Components: hdfs
Reporter: Mark Miller
Assignee: Mark Miller
{noformat}
java.lang.AssertionError: Could not find new collection awholynewcollection_1
at
__randomizedtesting.SeedInfo.seed([655D020D02309D33:E4BB8C15756FFD0F]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkForCollection(AbstractFullDistribZkTestBase.java:1642)
at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:723)
at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6424) The hdfs block cache BLOCKCACHE_WRITE_ENABLED is not defaulting to false like it should.
[ https://issues.apache.org/jira/browse/SOLR-6424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108522#comment-14108522 ] ASF subversion and git services commented on SOLR-6424: --- Commit 1620181 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1620181 ] SOLR-6424: The hdfs block cache BLOCKCACHE_WRITE_ENABLED is not defaulting to false like it should. May be related to the SOLR-6423 fail. The hdfs block cache BLOCKCACHE_WRITE_ENABLED is not defaulting to false like it should. Key: SOLR-6424 URL: https://issues.apache.org/jira/browse/SOLR-6424 Project: Solr Issue Type: Bug Components: hdfs Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.11 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
