[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_40-ea-b09) - Build # 4527 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4527/ Java: 32bit/jdk1.8.0_40-ea-b09 -server -XX:+UseParallelGC (asserts: false) 1 tests failed. FAILED: org.apache.solr.handler.component.SuggestComponentTest.testReloadAllSuggester Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([9C16D2955917D8A5:6181189B02A945EA]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:730) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:697) at org.apache.solr.handler.component.SuggestComponentTest.testReloadAllSuggester(SuggestComponentTest.java:157) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Caused by: java.io.FileNotFoundException: C:\Users\Je
[jira] [Assigned] (LUCENE-6149) Infix suggesters' highlighting, allTermsRequired options are hardwired and not configurable for non-contextual lookup
[
https://issues.apache.org/jira/browse/LUCENE-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe reassigned LUCENE-6149:
-
Assignee: Tomás Fernández Löbbe
> Infix suggesters' highlighting, allTermsRequired options are hardwired and
> not configurable for non-contextual lookup
> -
>
> Key: LUCENE-6149
> URL: https://issues.apache.org/jira/browse/LUCENE-6149
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/other
>Affects Versions: 4.9, 4.10.1, 4.10.2, 4.10.3
>Reporter: Boon Low
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Labels: suggester
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6149.patch
>
>
> Highlighting and allTermsRequired are hardwired in _AnalyzingInfixSuggester_
> for non-contextual lookup (via _Lookup_) see *true*, *true* below:
> {code:title=AnalyzingInfixSuggester.java (extends Lookup.java) }
> public List lookup(CharSequence key, Set contexts,
> boolean onlyMorePopular, int num) throws IOException {
> return lookup(key, contexts, num, true, true);
> }
> /** Lookup, without any context. */
> public List lookup(CharSequence key, int num, boolean
> allTermsRequired, boolean doHighlight) throws IOException {
> return lookup(key, null, num, allTermsRequired, doHighlight);
> }
> {code}
> {code:title=Lookup.java}
> public List lookup(CharSequence key, boolean onlyMorePopular,
> int num) throws IOException {
> return lookup(key, null, onlyMorePopular, num);
> }
> {code}
> The above means the majority of the current infix suggester lookup always
> return highlighted results with allTermsRequired in effect. There is no way
> to change this despite the options and improvement of LUCENE-6050, made to
> incorporate Boolean lookup clauses (MUST/SHOULD). This shortcoming has also
> been reported in SOLR-6648.
> The suggesters (AnalyzingInfixSuggester, BlendedInfixSuggester) should
> provide a proper mechanism to set defaults for highlighting and
> "allTermsRequired", e.g. in constructors (and in Solr factories, thus
> configurable via solrconfig.xml).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6149) Infix suggesters' highlighting, allTermsRequired options are hardwired and not configurable for non-contextual lookup
[
https://issues.apache.org/jira/browse/LUCENE-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262751#comment-14262751
]
Tomás Fernández Löbbe commented on LUCENE-6149:
---
I didn't see this patch yet, but as I said in SOLR-6648, I think it makes sense
to set those defaults in the constructor.
> Infix suggesters' highlighting, allTermsRequired options are hardwired and
> not configurable for non-contextual lookup
> -
>
> Key: LUCENE-6149
> URL: https://issues.apache.org/jira/browse/LUCENE-6149
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/other
>Affects Versions: 4.9, 4.10.1, 4.10.2, 4.10.3
>Reporter: Boon Low
>Priority: Minor
> Labels: suggester
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6149.patch
>
>
> Highlighting and allTermsRequired are hardwired in _AnalyzingInfixSuggester_
> for non-contextual lookup (via _Lookup_) see *true*, *true* below:
> {code:title=AnalyzingInfixSuggester.java (extends Lookup.java) }
> public List lookup(CharSequence key, Set contexts,
> boolean onlyMorePopular, int num) throws IOException {
> return lookup(key, contexts, num, true, true);
> }
> /** Lookup, without any context. */
> public List lookup(CharSequence key, int num, boolean
> allTermsRequired, boolean doHighlight) throws IOException {
> return lookup(key, null, num, allTermsRequired, doHighlight);
> }
> {code}
> {code:title=Lookup.java}
> public List lookup(CharSequence key, boolean onlyMorePopular,
> int num) throws IOException {
> return lookup(key, null, onlyMorePopular, num);
> }
> {code}
> The above means the majority of the current infix suggester lookup always
> return highlighted results with allTermsRequired in effect. There is no way
> to change this despite the options and improvement of LUCENE-6050, made to
> incorporate Boolean lookup clauses (MUST/SHOULD). This shortcoming has also
> been reported in SOLR-6648.
> The suggesters (AnalyzingInfixSuggester, BlendedInfixSuggester) should
> provide a proper mechanism to set defaults for highlighting and
> "allTermsRequired", e.g. in constructors (and in Solr factories, thus
> configurable via solrconfig.xml).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5147) Support Block Join documents in DIH
[ https://issues.apache.org/jira/browse/SOLR-5147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262736#comment-14262736 ] Mikhail Khludnev commented on SOLR-5147: @noble.paul, nope @elyograg, would you mind to share your achievement? > Support Block Join documents in DIH > --- > > Key: SOLR-5147 > URL: https://issues.apache.org/jira/browse/SOLR-5147 > Project: Solr > Issue Type: Sub-task >Reporter: Vadim Kirilchuk >Assignee: Noble Paul > Fix For: 4.9, Trunk > > Attachments: SOLR-5147.patch, SOLR-5147.patch > > > DIH should be able to index hierarchical documents, i.e. it should be able to > work with SolrInputDocuments#addChildDocument. > There was patch in SOLR-3076: > https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch > But it is not uptodate and far from being complete. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2413 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2413/ 2 tests failed. REGRESSION: org.apache.solr.cloud.TestZkChroot.testChrootBootstrap Error Message: Captured an uncaught exception in thread: Thread[id=1067, name=coreZkRegister-512-thread-1, state=RUNNABLE, group=TGRP-TestZkChroot] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=1067, name=coreZkRegister-512-thread-1, state=RUNNABLE, group=TGRP-TestZkChroot] at __randomizedtesting.SeedInfo.seed([C8E55510EF5E3534:EEE4C73539D9B98E]:0) Caused by: java.lang.AssertionError: 1 at __randomizedtesting.SeedInfo.seed([C8E55510EF5E3534]:0) at org.apache.solr.core.CachingDirectoryFactory.close(CachingDirectoryFactory.java:202) at org.apache.solr.core.SolrCore.close(SolrCore.java:1172) at org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:304) at org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:162) at org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:124) at org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:313) at org.apache.solr.cloud.ZkController.joinElection(ZkController.java:1031) at org.apache.solr.cloud.ZkController.register(ZkController.java:846) at org.apache.solr.cloud.ZkController.register(ZkController.java:803) at org.apache.solr.core.ZkContainer$2.run(ZkContainer.java:208) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestZkChroot Error Message: ERROR: SolrIndexSearcher opens=3 closes=2 Stack Trace: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=3 closes=2 at __randomizedtesting.SeedInfo.seed([C8E55510EF5E3534]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:447) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:187) at sun.reflect.GeneratedMethodAccessor31.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 9250 lines...] [junit4] Suite: org.apache.solr.cloud.TestZkChroot [junit4] 2> Creating dataDir: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/solr/build/solr-core/test/J3/temp/solr.cloud.TestZkChroot-C8E55510EF5E3534-001/init-core-data-001 [junit4] 2> 467727 T1048 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl (false) and clientAuth (false) [jun
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2412 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2412/
1 tests failed.
FAILED: org.apache.solr.core.TestDynamicLoading.testDistribSearch
Error Message:
New version of class is not loaded { "responseHeader":{ "status":404,
"QTime":3}, "error":{ "msg":"no such blob or version available: test/2",
"code":404}}
Stack Trace:
java.lang.AssertionError: New version of class is not loaded {
"responseHeader":{
"status":404,
"QTime":3},
"error":{
"msg":"no such blob or version available: test/2",
"code":404}}
at
__randomizedtesting.SeedInfo.seed([63B2098D48F5C995:E25487953FAAA9A9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestDynamicLoading.dynamicLoading(TestDynamicLoading.java:154)
at
org.apache.solr.core.TestDynamicLoading.doTest(TestDynamicLoading.java:64)
at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapt
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 721 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/721/ 2 tests failed. REGRESSION: org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testDistribSearch Error Message: IOException occured when talking to server at: http://127.0.0.1:55933/db_cgh/b/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:55933/db_cgh/b/collection1 at __randomizedtesting.SeedInfo.seed([F3AAE198B3ED19D5:724C6F80C4B279E9]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:572) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:214) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:210) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:302) at org.apache.solr.cloud.CloudInspectUtil.compareResults(CloudInspectUtil.java:223) at org.apache.solr.cloud.CloudInspectUtil.compareResults(CloudInspectUtil.java:165) at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:413) at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.doTest(FullSolrCloudDistribCmdsTest.java:143) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868) 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.carrotsea
[jira] [Created] (SOLR-6904) Remove deprecated Circle/Rect format from trunk & 5.0
David Smiley created SOLR-6904:
--
Summary: Remove deprecated Circle/Rect format from trunk & 5.0
Key: SOLR-6904
URL: https://issues.apache.org/jira/browse/SOLR-6904
Project: Solr
Issue Type: Task
Components: spatial
Reporter: David Smiley
Assignee: David Smiley
Fix For: 5.0, Trunk
The Solr 4 spatial code introduced a custom format for a rectangle and a
Circle. In 4.3, it was deprecated in favor of WKT, which no longer required
JTS for WKT parsing. It should be removed now. The syntax is governed by
LegacyShapeReadWriterFormat (Spatial4j) referenced by Solr's
AbstractSpatialFieldType.parseShape.
Examples of the syntax to be removed are as follows:
* Rect: {{-74.093 41.042 -69.347 44.558}}
* Circle: {{Circle(4.56,1.23 d=0.0710)}}
In addition to use in indexing & querying, the rect shape is also found in the
worldBounds attribute (optional, only required if you use geo=false)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6483) Refactor some methods in MiniSolrCloudCluster tests
[ https://issues.apache.org/jira/browse/SOLR-6483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-6483. -- Resolution: Fixed Fix Version/s: Trunk 5.0 Thanks David! There's doubtless more that we can do here, but my need evaporated. We can open other JIRAs as necessary. Also fixed bad EOL for some other checkin (RequestParmas and BlobStoreTestRequestHandlerV2) > Refactor some methods in MiniSolrCloudCluster tests > --- > > Key: SOLR-6483 > URL: https://issues.apache.org/jira/browse/SOLR-6483 > Project: Solr > Issue Type: Improvement >Affects Versions: 5.0, Trunk >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Fix For: 5.0, Trunk > > Attachments: SOLR-6483.patch, SOLR-6483.patch > > > Looking at whether we can provide some ease-of-use methods in > MiniSolrCloudCluster -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6483) Refactor some methods in MiniSolrCloudCluster tests
[ https://issues.apache.org/jira/browse/SOLR-6483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262657#comment-14262657 ] ASF subversion and git services commented on SOLR-6483: --- Commit 1648938 from [~erickoerickson] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1648938 ] SOLR-6483, Refactor some methods in MiniSolrCloudCluster tests > Refactor some methods in MiniSolrCloudCluster tests > --- > > Key: SOLR-6483 > URL: https://issues.apache.org/jira/browse/SOLR-6483 > Project: Solr > Issue Type: Improvement >Affects Versions: 5.0, Trunk >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-6483.patch, SOLR-6483.patch > > > Looking at whether we can provide some ease-of-use methods in > MiniSolrCloudCluster -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.8.0_40-ea-b09) - Build # 4422 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4422/
Java: 64bit/jdk1.8.0_40-ea-b09 -XX:-UseCompressedOops -XX:+UseSerialGC
(asserts: false)
1 tests failed.
FAILED: org.apache.solr.handler.TestSolrConfigHandlerCloud.testDistribSearch
Error Message:
Could not get expected value null for path [response, params, y, c] full
output { "responseHeader":{ "status":0, "QTime":0}, "response":{
"znodeVersion":1, "params":{ "x":{ "a":"A val",
"b":"B val", "":{"v":0}}, "y":{ "c":"CY val",
"b":"BY val", "":{"v":0}
Stack Trace:
java.lang.AssertionError: Could not get expected value null for path
[response, params, y, c] full output {
"responseHeader":{
"status":0,
"QTime":0},
"response":{
"znodeVersion":1,
"params":{
"x":{
"a":"A val",
"b":"B val",
"":{"v":0}},
"y":{
"c":"CY val",
"b":"BY val",
"":{"v":0}
at
__randomizedtesting.SeedInfo.seed([BD2E848BFAE7E95E:3CC80A938DB88962]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:231)
at
org.apache.solr.handler.TestSolrConfigHandlerCloud.testReqParams(TestSolrConfigHandlerCloud.java:262)
at
org.apache.solr.handler.TestSolrConfigHandlerCloud.doTest(TestSolrConfigHandlerCloud.java:61)
at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
at sun.reflect.GeneratedMethodAccessor99.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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.car
[jira] [Updated] (SOLR-6797) Add score=degrees|kilometers|miles for AbstractSpatialFieldType
[
https://issues.apache.org/jira/browse/SOLR-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-6797:
---
Attachment: SOLR-6797.patch
Here's a patch, modified from the most recent one you (Ishan) put up on
ReviewBoard. I hoped to upload it to the same review ticket but I saw no way
to do so... perhaps since you created it only you can? I'd appreciate it it
you add this one if for no other reason then to see what my changes were
exactly.
>From memory...
* A test or two failed and it was related to a modification to the schema to
use kilometers without correspondingly updated maxDistErr.
* Some places were checking units.equals("degrees") when in fact the
distanceUnits can be used because you've got a back-compat instance.
* I refactored the units & distanceUnits initialization logic. It should be
equivalent, I think. I didn't want parseDistanceUnits concerned with
initialization-only logic.
* Moved DistanceUnits out of the spatial sub-package you made... it was the
only class there and I felt it didn't warrant a package. New packages require
package level javadocs too. "ant precommit" exposes such things.
> Add score=degrees|kilometers|miles for AbstractSpatialFieldType
> ---
>
> Key: SOLR-6797
> URL: https://issues.apache.org/jira/browse/SOLR-6797
> Project: Solr
> Issue Type: Improvement
> Components: spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch,
> SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch
>
>
> Annoyingly, the units="degrees" attribute is required for fields extending
> AbstractSpatialFieldType (e.g. RPT, BBox). And it doesn't really have any
> effect. I propose the following:
> * Simply drop the attribute; ignore it if someone sets it to "degrees" (for
> back-compat).
> * When using score="distance", or score=area or area2D (as seen in BBoxField)
> then use kilometers if geo=true, otherwise degrees.
> * Add support for score=degrees|kilometers|miles|degrees
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6894) Introduce SolrNodeClient API
[
https://issues.apache.org/jira/browse/SOLR-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262653#comment-14262653
]
Yonik Seeley commented on SOLR-6894:
Oh, I see what you mean by forCore/forCollection now. I like it!
bq. but on a CloudSolrClient it will return a client that talks to a specific
core in the cluster, with a default parameter of distrib=false, which is useful
for debugging.
Or, more generally, forCore/forCollection could take default parameters as an
argument:
x.forCore("core1", params("distrib",false, "wt","json", "indent",true) )
Although it's difficult today to add additional parameters on update requests,
so we should really think about adding that capability too:
client.add( sdoc, params("commitWithin",5000, "_version_",1, ...) )
> Introduce SolrNodeClient API
>
>
> Key: SOLR-6894
> URL: https://issues.apache.org/jira/browse/SOLR-6894
> Project: Solr
> Issue Type: New Feature
> Components: SolrJ
>Affects Versions: 5.0, Trunk
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: SOLR-6894.patch
>
>
> At the moment, it isn't possible to use a single SolrServer instance to
> create new cores via CoreAdmin on an empty node, and then query those nodes.
> MultiCoreSolrServer is a utility class that does just that, by allowing you
> to create child SolrServer instances for individual cores that share the
> underlying HttpClient.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6797) Add score=degrees|kilometers|miles for AbstractSpatialFieldType
[ https://issues.apache.org/jira/browse/SOLR-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-6797: --- Fix Version/s: Trunk 5.0 Assignee: David Smiley > Add score=degrees|kilometers|miles for AbstractSpatialFieldType > --- > > Key: SOLR-6797 > URL: https://issues.apache.org/jira/browse/SOLR-6797 > Project: Solr > Issue Type: Improvement > Components: spatial >Reporter: David Smiley >Assignee: David Smiley > Fix For: 5.0, Trunk > > Attachments: SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch, > SOLR-6797.patch, SOLR-6797.patch > > > Annoyingly, the units="degrees" attribute is required for fields extending > AbstractSpatialFieldType (e.g. RPT, BBox). And it doesn't really have any > effect. I propose the following: > * Simply drop the attribute; ignore it if someone sets it to "degrees" (for > back-compat). > * When using score="distance", or score=area or area2D (as seen in BBoxField) > then use kilometers if geo=true, otherwise degrees. > * Add support for score=degrees|kilometers|miles|degrees -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6894) Introduce SolrNodeClient API
[ https://issues.apache.org/jira/browse/SOLR-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated SOLR-6894: Summary: Introduce SolrNodeClient API (was: Add MultiCoreSolrServer ) > Introduce SolrNodeClient API > > > Key: SOLR-6894 > URL: https://issues.apache.org/jira/browse/SOLR-6894 > Project: Solr > Issue Type: New Feature > Components: SolrJ >Affects Versions: 5.0, Trunk >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: SOLR-6894.patch > > > At the moment, it isn't possible to use a single SolrServer instance to > create new cores via CoreAdmin on an empty node, and then query those nodes. > MultiCoreSolrServer is a utility class that does just that, by allowing you > to create child SolrServer instances for individual cores that share the > underlying HttpClient. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6894) Add MultiCoreSolrServer
[
https://issues.apache.org/jira/browse/SOLR-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262648#comment-14262648
]
Alan Woodward commented on SOLR-6894:
-
I've rethought this slightly, what I want to do now is introduce another
abstraction, SolrNodeClient, which extends SolrClient and adds two methods:
* SolrClient forCore(String core)
* SolrClient forCollection(String collection)
HttpSolrClient and CloudSolrClient both extend SolrNodeClient. You create a
SolrNodeClient to point at a particular node (or zk-discovered cluster, in the
case of CloudSolrClient), which you can then use for admin requests. If you
want to execute requests against a particular collection, call
#forCollection(String collection), and you get a specialised SolrClient that
shares its resources (HttpClient, ZkClient, etc) with the parent
SolrNodeClient. Calling #forCore() on an HttpSolrClient has the same effect as
calling #forCollection(), but on a CloudSolrClient it will return a client that
talks to a specific core in the cluster, with a default parameter of
distrib=false, which is useful for debugging.
This means that your API when communicating with an empty node would be
something like:
{code}
SolrNodeClient client = new HttpSolrClient(pathToMultiCoreServer);
CoreAdminRequest.Create createReq = new Create();
createReq.setCoreName("myCore");
createReq.setConfigSet("myConfigSet");
client.request(createReq);
SolrClient myCoreClient = client.forCore("myCore")
{code}
and for SolrCloud:
{code}
CloudSolrClient clusterClient = new CloudSolrClient(zkPath);
CollectionAdminRequest.Create createReq = new CollectionAdminRequest.Create();
createReq.setName("myCollection")
createReq.setConfig("myConfig")
clusterClient.execute(createReq);
SolrClient collectionClient = client.forCollection("myCollection");
{code}
> Add MultiCoreSolrServer
>
>
> Key: SOLR-6894
> URL: https://issues.apache.org/jira/browse/SOLR-6894
> Project: Solr
> Issue Type: New Feature
> Components: SolrJ
>Affects Versions: 5.0, Trunk
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: SOLR-6894.patch
>
>
> At the moment, it isn't possible to use a single SolrServer instance to
> create new cores via CoreAdmin on an empty node, and then query those nodes.
> MultiCoreSolrServer is a utility class that does just that, by allowing you
> to create child SolrServer instances for individual cores that share the
> underlying HttpClient.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_20) - Build # 11666 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11666/ Java: 64bit/jdk1.8.0_20 -XX:+UseCompressedOops -XX:+UseSerialGC (asserts: true) All tests passed Build Log: [...truncated 59522 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:529: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:436: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/extra-targets.xml:105: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/extra-targets.xml:204: The following files are missing svn:eol-style (or binary svn:mime-type): * ./solr/core/src/java/org/apache/solr/core/RequestParams.java * ./solr/core/src/test/org/apache/solr/core/BlobStoreTestRequestHandlerV2.java Total time: 80 minutes 3 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.8.0_20 -XX:+UseCompressedOops -XX:+UseSerialGC (asserts: true) 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] [Comment Edited] (SOLR-6900) bin/post improvements needed
[ https://issues.apache.org/jira/browse/SOLR-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262644#comment-14262644 ] Alexandre Rafalovitch edited comment on SOLR-6900 at 1/1/15 7:27 PM: - Also, the help message is problematic. The underlying simplepost tool talks about using *-h* but you can't actually use that as the first parameter is the collection name. A bit confusing. But even if I give dummy collection name and -h, I am not sure the examples given will actually work. So, maybe it's own help is needed for the tool. was (Author: arafalov): Also, the help message is problematic. The underlying simplepost tool talks about using *-h* but you can't actually use that as the first parameter is the collection name. A bit confusing. > bin/post improvements needed > > > Key: SOLR-6900 > URL: https://issues.apache.org/jira/browse/SOLR-6900 > Project: Solr > Issue Type: Bug >Affects Versions: 5.0, Trunk >Reporter: Erik Hatcher >Assignee: Erik Hatcher > Fix For: 5.0, Trunk > > > * Fix glob patterns. They don't work as expected: bin/post collection1 > \*.xml expands \*.xml such that the script gets all the file names as > parameters not just literally "\*.xml" > * Add error handling to check that the collection exists > * Create Windows version -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6900) bin/post improvements needed
[ https://issues.apache.org/jira/browse/SOLR-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262644#comment-14262644 ] Alexandre Rafalovitch commented on SOLR-6900: - Also, the help message is problematic. The underlying simplepost tool talks about using *-h* but you can't actually use that as the first parameter is the collection name. A bit confusing. > bin/post improvements needed > > > Key: SOLR-6900 > URL: https://issues.apache.org/jira/browse/SOLR-6900 > Project: Solr > Issue Type: Bug >Affects Versions: 5.0, Trunk >Reporter: Erik Hatcher >Assignee: Erik Hatcher > Fix For: 5.0, Trunk > > > * Fix glob patterns. They don't work as expected: bin/post collection1 > \*.xml expands \*.xml such that the script gets all the file names as > parameters not just literally "\*.xml" > * Add error handling to check that the collection exists > * Create Windows version -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_67) - Build # 11665 - Failure!
Just saw this when merging SOLR-6483, I'll take care of it in a few minutes. On Thu, Jan 1, 2015 at 9:18 AM, Policeman Jenkins Server wrote: > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11665/ > Java: 64bit/jdk1.7.0_67 -XX:+UseCompressedOops -XX:+UseSerialGC (asserts: > true) > > All tests passed > > Build Log: > [...truncated 59507 lines...] > BUILD FAILED > /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:529: The following > error occurred while executing this line: > /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:436: The following > error occurred while executing this line: > /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/extra-targets.xml:105: The > following error occurred while executing this line: > /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/extra-targets.xml:204: The > following files are missing svn:eol-style (or binary svn:mime-type): > * ./solr/core/src/java/org/apache/solr/core/RequestParams.java > * ./solr/core/src/test/org/apache/solr/core/BlobStoreTestRequestHandlerV2.java > > Total time: 79 minutes 14 seconds > Build step 'Invoke Ant' marked build as failure > [description-setter] Description set: Java: 64bit/jdk1.7.0_67 > -XX:+UseCompressedOops -XX:+UseSerialGC (asserts: true) > 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2411 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2411/ 2 tests failed. REGRESSION: org.apache.lucene.analysis.uima.UIMATypeAwareAnalyzerTest.testRandomStrings Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([8BC27250440723B0]:0) FAILED: junit.framework.TestSuite.org.apache.lucene.analysis.uima.UIMATypeAwareAnalyzerTest Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([8BC27250440723B0]:0) Build Log: [...truncated 3850 lines...] [junit4] Suite: org.apache.lucene.analysis.uima.UIMATypeAwareAnalyzerTest [junit4] 2> janv. 01, 2015 1:01:58 PM WhitespaceTokenizer initialize [junit4] 2> INFOS: "Whitespace tokenizer successfully initialized" [junit4] 2> janv. 01, 2015 1:01:58 PM WhitespaceTokenizer typeSystemInit [junit4] 2> INFOS: "Whitespace tokenizer typesystem initialized" [junit4] 2> janv. 01, 2015 1:01:58 PM WhitespaceTokenizer process [junit4] 2> INFOS: "Whitespace tokenizer starts processing" [junit4] 2> janv. 01, 2015 1:01:58 PM WhitespaceTokenizer process [junit4] 2> INFOS: "Whitespace tokenizer finished processing" [junit4] 2> janv. 01, 2015 3:01:55 PM com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate [junit4] 2> AVERTISSEMENT: Suite execution timed out: org.apache.lucene.analysis.uima.UIMATypeAwareAnalyzerTest [junit4] 2> jstack at approximately timeout time [junit4] 2> "TEST-UIMATypeAwareAnalyzerTest.testRandomStrings-seed#[8BC27250440723B0]" ID=23 RUNNABLE [junit4] 2>at java.util.HashMap.getEntry(HashMap.java:465) [junit4] 2>at java.util.HashMap.containsKey(HashMap.java:449) [junit4] 2>at java.util.HashSet.contains(HashSet.java:201) [junit4] 2>at org.apache.uima.analysis_engine.impl.AnalysisEngineManagementImpl.setName(AnalysisEngineManagementImpl.java:242) [junit4] 2>at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.initialize(AnalysisEngineImplBase.java:181) [junit4] 2>at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.initialize(AggregateAnalysisEngine_impl.java:127) [junit4] 2>at org.apache.uima.impl.AnalysisEngineFactory_impl.produceResource(AnalysisEngineFactory_impl.java:94) [junit4] 2>at org.apache.uima.impl.CompositeResourceFactory_impl.produceResource(CompositeResourceFactory_impl.java:62) [junit4] 2>at org.apache.uima.UIMAFramework.produceResource(UIMAFramework.java:267) [junit4] 2>at org.apache.uima.UIMAFramework.produceAnalysisEngine(UIMAFramework.java:335) [junit4] 2>at org.apache.lucene.analysis.uima.ae.BasicAEProvider.getAE(BasicAEProvider.java:73) [junit4] 2>at org.apache.lucene.analysis.uima.BaseUIMATokenizer.analyzeInput(BaseUIMATokenizer.java:64) [junit4] 2>at org.apache.lucene.analysis.uima.UIMATypeAwareAnnotationsTokenizer.initializeIterator(UIMATypeAwareAnnotationsTokenizer.java:72) [junit4] 2>at org.apache.lucene.analysis.uima.UIMATypeAwareAnnotationsTokenizer.incrementToken(UIMATypeAwareAnnotationsTokenizer.java:94) [junit4] 2>at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException(BaseTokenStreamTestCase.java:388) [junit4] 2>at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:494) [junit4] 2>at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:428) [junit4] 2>at org.apache.lucene.analysis.uima.UIMATypeAwareAnalyzerTest.testRandomStrings(UIMATypeAwareAnalyzerTest.java:64) [junit4] 2>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit4] 2>at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [junit4] 2>at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit4] 2>at java.lang.reflect.Method.invoke(Method.java:606) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) [junit4] 2>at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) [junit4] 2>at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) [junit4] 2>at org.apache.lucene.util.AbstractBeforeAfte
[jira] [Commented] (SOLR-6483) Refactor some methods in MiniSolrCloudCluster tests
[ https://issues.apache.org/jira/browse/SOLR-6483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262641#comment-14262641 ] ASF subversion and git services commented on SOLR-6483: --- Commit 1648923 from [~erickoerickson] in branch 'dev/trunk' [ https://svn.apache.org/r1648923 ] SOLR-6483, Refactor some methods in MiniSolrCloudCluster tests > Refactor some methods in MiniSolrCloudCluster tests > --- > > Key: SOLR-6483 > URL: https://issues.apache.org/jira/browse/SOLR-6483 > Project: Solr > Issue Type: Improvement >Affects Versions: 5.0, Trunk >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-6483.patch, SOLR-6483.patch > > > Looking at whether we can provide some ease-of-use methods in > MiniSolrCloudCluster -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6483) Refactor some methods in MiniSolrCloudCluster tests
[ https://issues.apache.org/jira/browse/SOLR-6483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-6483: - Attachment: SOLR-6483.patch Patch with changes necessary for the CloudSolrServer <- CloudSolrClient changes, plus CHANGES.txt Thanks David! > Refactor some methods in MiniSolrCloudCluster tests > --- > > Key: SOLR-6483 > URL: https://issues.apache.org/jira/browse/SOLR-6483 > Project: Solr > Issue Type: Improvement >Affects Versions: 5.0, Trunk >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-6483.patch, SOLR-6483.patch > > > Looking at whether we can provide some ease-of-use methods in > MiniSolrCloudCluster -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b34) - Build # 11834 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11834/
Java: 64bit/jdk1.9.0-ea-b34 -XX:-UseCompressedOops -XX:+UseG1GC (asserts: true)
1 tests failed.
FAILED: org.apache.solr.handler.TestSolrConfigHandlerCloud.testDistribSearch
Error Message:
Could not get expected value P val for path [response, params, y, p] full
output { "responseHeader":{ "status":0, "QTime":0}, "response":{
"znodeVersion":1, "params":{ "x":{ "a":"A val",
"b":"B val", "":{"v":0}}, "y":{ "c":"CY val",
"b":"BY val", "":{"v":0}
Stack Trace:
java.lang.AssertionError: Could not get expected value P val for path
[response, params, y, p] full output {
"responseHeader":{
"status":0,
"QTime":0},
"response":{
"znodeVersion":1,
"params":{
"x":{
"a":"A val",
"b":"B val",
"":{"v":0}},
"y":{
"c":"CY val",
"b":"BY val",
"":{"v":0}
at
__randomizedtesting.SeedInfo.seed([55E82118427A35BF:D40EAF0035255583]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:231)
at
org.apache.solr.handler.TestSolrConfigHandlerCloud.testReqParams(TestSolrConfigHandlerCloud.java:253)
at
org.apache.solr.handler.TestSolrConfigHandlerCloud.doTest(TestSolrConfigHandlerCloud.java:61)
at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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.carrotsea
[jira] [Commented] (LUCENE-6119) Add auto-io-throttle to ConcurrentMergeScheduler
[ https://issues.apache.org/jira/browse/LUCENE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262616#comment-14262616 ] Michael McCandless commented on LUCENE-6119: bq. Did you mean 250 milliseconds or 250 seconds? Woops! I'll fix, thanks. > Add auto-io-throttle to ConcurrentMergeScheduler > > > Key: LUCENE-6119 > URL: https://issues.apache.org/jira/browse/LUCENE-6119 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-6119.patch, LUCENE-6119.patch, LUCENE-6119.patch, > LUCENE-6119.patch > > > This method returns number of "incoming" bytes IW has written since it > was opened, excluding merging. > It tracks flushed segments, new commits (segments_N), incoming > files/segments by addIndexes, newly written live docs / doc values > updates files. > It's an easy statistic for IW to track and should be useful to help > applications more intelligently set defaults for IO throttling > (RateLimiter). > For example, an application that does hardly any indexing but finally > triggered a large merge can afford to heavily throttle that large > merge so it won't interfere with ongoing searches. > But an application that's causing IW to write new bytes at 50 MB/sec > must set a correspondingly higher IO throttling otherwise merges will > clearly fall behind. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6119) Add auto-io-throttle to ConcurrentMergeScheduler
[ https://issues.apache.org/jira/browse/LUCENE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262614#comment-14262614 ] Robert Muir commented on LUCENE-6119: - +1, I really like this approach. > Add auto-io-throttle to ConcurrentMergeScheduler > > > Key: LUCENE-6119 > URL: https://issues.apache.org/jira/browse/LUCENE-6119 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-6119.patch, LUCENE-6119.patch, LUCENE-6119.patch, > LUCENE-6119.patch > > > This method returns number of "incoming" bytes IW has written since it > was opened, excluding merging. > It tracks flushed segments, new commits (segments_N), incoming > files/segments by addIndexes, newly written live docs / doc values > updates files. > It's an easy statistic for IW to track and should be useful to help > applications more intelligently set defaults for IO throttling > (RateLimiter). > For example, an application that does hardly any indexing but finally > triggered a large merge can afford to heavily throttle that large > merge so it won't interfere with ongoing searches. > But an application that's causing IW to write new bytes at 50 MB/sec > must set a correspondingly higher IO throttling otherwise merges will > clearly fall behind. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6119) Add auto-io-throttle to ConcurrentMergeScheduler
[
https://issues.apache.org/jira/browse/LUCENE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262606#comment-14262606
]
Robert Muir commented on LUCENE-6119:
-
{code}
// Defensive: sleep for at most 250 msec; the loop above will call us again
if we should keep sleeping:
if (curPauseNS > 250L*10) {
curPauseNS = 250L*10;
}
{code}
Did you mean 250 milliseconds or 250 seconds?
> Add auto-io-throttle to ConcurrentMergeScheduler
>
>
> Key: LUCENE-6119
> URL: https://issues.apache.org/jira/browse/LUCENE-6119
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6119.patch, LUCENE-6119.patch, LUCENE-6119.patch,
> LUCENE-6119.patch
>
>
> This method returns number of "incoming" bytes IW has written since it
> was opened, excluding merging.
> It tracks flushed segments, new commits (segments_N), incoming
> files/segments by addIndexes, newly written live docs / doc values
> updates files.
> It's an easy statistic for IW to track and should be useful to help
> applications more intelligently set defaults for IO throttling
> (RateLimiter).
> For example, an application that does hardly any indexing but finally
> triggered a large merge can afford to heavily throttle that large
> merge so it won't interfere with ongoing searches.
> But an application that's causing IW to write new bytes at 50 MB/sec
> must set a correspondingly higher IO throttling otherwise merges will
> clearly fall behind.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_67) - Build # 11665 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11665/ Java: 64bit/jdk1.7.0_67 -XX:+UseCompressedOops -XX:+UseSerialGC (asserts: true) All tests passed Build Log: [...truncated 59507 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:529: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:436: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/extra-targets.xml:105: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/extra-targets.xml:204: The following files are missing svn:eol-style (or binary svn:mime-type): * ./solr/core/src/java/org/apache/solr/core/RequestParams.java * ./solr/core/src/test/org/apache/solr/core/BlobStoreTestRequestHandlerV2.java Total time: 79 minutes 14 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.7.0_67 -XX:+UseCompressedOops -XX:+UseSerialGC (asserts: true) 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-MAVEN] Lucene-Solr-Maven-5.x #805: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/805/ 3 tests failed. FAILED: org.apache.solr.hadoop.MapReduceIndexerToolArgumentParserTest.org.apache.solr.hadoop.MapReduceIndexerToolArgumentParserTest Error Message: null Stack Trace: java.lang.AssertionError: null at __randomizedtesting.SeedInfo.seed([E6710691D8727ABF]:0) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.before(TestRuleTemporaryFilesCleanup.java:105) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.before(TestRuleAdapter.java:26) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:35) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.solr.hadoop.MorphlineBasicMiniMRTest.testPathParts Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([17085692855BB42C]:0) FAILED: org.apache.solr.hadoop.MorphlineBasicMiniMRTest.org.apache.solr.hadoop.MorphlineBasicMiniMRTest Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([17085692855BB42C]:0) Build Log: [...truncated 54117 lines...] BUILD FAILED /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:552: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:204: The following error occurred while executing this line: : Java returned: 1 Total time: 351 minutes 45 seconds Build step 'Invoke Ant' marked build as failure 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
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_40-ea-b09) - Build # 11833 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11833/ Java: 64bit/jdk1.8.0_40-ea-b09 -XX:-UseCompressedOops -XX:+UseG1GC (asserts: true) 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeySafeLeaderTest Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([B09168A3B9A34E7]:0) FAILED: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([B09168A3B9A34E7]:0) Build Log: [...truncated 10003 lines...] [junit4] Suite: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest [junit4] 2> Creating dataDir: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.ChaosMonkeySafeLeaderTest-B09168A3B9A34E7-001/init-core-data-001 [junit4] 2> 526626 T3645 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl (false) and clientAuth (false) [junit4] 2> 526626 T3645 oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext system property: / [junit4] 2> 526632 T3645 oas.SolrTestCaseJ4.setUp ###Starting testDistribSearch [junit4] 2> 526633 T3645 oasc.ZkTestServer.run STARTING ZK TEST SERVER [junit4] 1> client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 526634 T3646 oasc.ZkTestServer$ZKServerMain.runFromConfig Starting server [junit4] 2> 526733 T3645 oasc.ZkTestServer.run start zk server on port:52903 [junit4] 2> 526734 T3645 oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default ZkCredentialsProvider [junit4] 2> 526735 T3645 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2> 526739 T3653 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@2b81963b name:ZooKeeperConnection Watcher:127.0.0.1:52903 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 526739 T3645 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2> 526740 T3645 oascc.SolrZkClient.createZkACLProvider Using default ZkACLProvider [junit4] 2> 526740 T3645 oascc.SolrZkClient.makePath makePath: /solr [junit4] 2> 526743 T3645 oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default ZkCredentialsProvider [junit4] 2> 526744 T3645 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2> 526746 T3656 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@3b03450 name:ZooKeeperConnection Watcher:127.0.0.1:52903/solr got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 526746 T3645 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2> 526747 T3645 oascc.SolrZkClient.createZkACLProvider Using default ZkACLProvider [junit4] 2> 526747 T3645 oascc.SolrZkClient.makePath makePath: /collections/collection1 [junit4] 2> 526749 T3645 oascc.SolrZkClient.makePath makePath: /collections/collection1/shards [junit4] 2> 526751 T3645 oascc.SolrZkClient.makePath makePath: /collections/control_collection [junit4] 2> 526753 T3645 oascc.SolrZkClient.makePath makePath: /collections/control_collection/shards [junit4] 2> 526755 T3645 oasc.AbstractZkTestCase.putConfig put /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2> 526756 T3645 oascc.SolrZkClient.makePath makePath: /configs/conf1/solrconfig.xml [junit4] 2> 526759 T3645 oasc.AbstractZkTestCase.putConfig put /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/schema15.xml to /configs/conf1/schema.xml [junit4] 2> 526759 T3645 oascc.SolrZkClient.makePath makePath: /configs/conf1/schema.xml [junit4] 2> 526761 T3645 oasc.AbstractZkTestCase.putConfig put /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml to /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 526761 T3645 oascc.SolrZkClient.makePath makePath: /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 526763 T3645 oasc.AbstractZkTestCase.putConfig put /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/stopwords.txt to /configs/conf1/stopwords.txt [junit4] 2> 526764 T3645 oascc.SolrZkClient.makePath makePath: /configs/conf1/stopwords.txt [junit4] 2> 526765 T3645 oasc.AbstractZkTestCase.putConfig put /mnt/ssd/jenkins/workspace/Lucene-Sol
[jira] [Resolved] (LUCENE-6146) Directory.copy -> Directory.copyFrom
[
https://issues.apache.org/jira/browse/LUCENE-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-6146.
-
Resolution: Fixed
> Directory.copy -> Directory.copyFrom
>
>
> Key: LUCENE-6146
> URL: https://issues.apache.org/jira/browse/LUCENE-6146
> Project: Lucene - Core
> Issue Type: Task
> Components: core/store
>Reporter: Robert Muir
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6146.patch
>
>
> Spinoff of LUCENE-4746.
> This method is currently:
> {code}
> copy(Directory to, String src, String dest, IOContext context)
> {code}
> But it would be better to restructure this so the destination directory is
> the one actually being changed by the operation:
> {code}
> copyFrom(Directory from, String src, String dest, IOContext context)
> {code}
> Besides fixing the order to make sense, adding it to the name might help
> prevent bugs like the current TrackingDirectoryWrapper impl (used by
> IndexWriter to track what files are used):
> {code}
> public void copy(Directory to, String src, String dest, IOContext context)
> throws IOException {
> createdFileNames.add(dest); // BUG!
> in.copy(to, src, dest, context);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6146) Directory.copy -> Directory.copyFrom
[
https://issues.apache.org/jira/browse/LUCENE-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262577#comment-14262577
]
ASF subversion and git services commented on LUCENE-6146:
-
Commit 1648854 from [~rcmuir] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1648854 ]
LUCENE-6146: Replaced Directory.copy() with Directory.copyFrom()
> Directory.copy -> Directory.copyFrom
>
>
> Key: LUCENE-6146
> URL: https://issues.apache.org/jira/browse/LUCENE-6146
> Project: Lucene - Core
> Issue Type: Task
> Components: core/store
>Reporter: Robert Muir
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6146.patch
>
>
> Spinoff of LUCENE-4746.
> This method is currently:
> {code}
> copy(Directory to, String src, String dest, IOContext context)
> {code}
> But it would be better to restructure this so the destination directory is
> the one actually being changed by the operation:
> {code}
> copyFrom(Directory from, String src, String dest, IOContext context)
> {code}
> Besides fixing the order to make sense, adding it to the name might help
> prevent bugs like the current TrackingDirectoryWrapper impl (used by
> IndexWriter to track what files are used):
> {code}
> public void copy(Directory to, String src, String dest, IOContext context)
> throws IOException {
> createdFileNames.add(dest); // BUG!
> in.copy(to, src, dest, context);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5147) Support Block Join documents in DIH
[ https://issues.apache.org/jira/browse/SOLR-5147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262575#comment-14262575 ] Noble Paul commented on SOLR-5147: -- Is the attached patch the final one? Does it work on both trunk and 5x ? > Support Block Join documents in DIH > --- > > Key: SOLR-5147 > URL: https://issues.apache.org/jira/browse/SOLR-5147 > Project: Solr > Issue Type: Sub-task >Reporter: Vadim Kirilchuk >Assignee: Noble Paul > Fix For: 4.9, Trunk > > Attachments: SOLR-5147.patch, SOLR-5147.patch > > > DIH should be able to index hierarchical documents, i.e. it should be able to > work with SolrInputDocuments#addChildDocument. > There was patch in SOLR-3076: > https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch > But it is not uptodate and far from being complete. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-5147) Support Block Join documents in DIH
[ https://issues.apache.org/jira/browse/SOLR-5147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-5147: Assignee: Noble Paul > Support Block Join documents in DIH > --- > > Key: SOLR-5147 > URL: https://issues.apache.org/jira/browse/SOLR-5147 > Project: Solr > Issue Type: Sub-task >Reporter: Vadim Kirilchuk >Assignee: Noble Paul > Fix For: 4.9, Trunk > > Attachments: SOLR-5147.patch, SOLR-5147.patch > > > DIH should be able to index hierarchical documents, i.e. it should be able to > work with SolrInputDocuments#addChildDocument. > There was patch in SOLR-3076: > https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch > But it is not uptodate and far from being complete. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6146) Directory.copy -> Directory.copyFrom
[
https://issues.apache.org/jira/browse/LUCENE-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262573#comment-14262573
]
ASF subversion and git services commented on LUCENE-6146:
-
Commit 1648851 from [~rcmuir] in branch 'dev/trunk'
[ https://svn.apache.org/r1648851 ]
LUCENE-6146: Replaced Directory.copy() with Directory.copyFrom()
> Directory.copy -> Directory.copyFrom
>
>
> Key: LUCENE-6146
> URL: https://issues.apache.org/jira/browse/LUCENE-6146
> Project: Lucene - Core
> Issue Type: Task
> Components: core/store
>Reporter: Robert Muir
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6146.patch
>
>
> Spinoff of LUCENE-4746.
> This method is currently:
> {code}
> copy(Directory to, String src, String dest, IOContext context)
> {code}
> But it would be better to restructure this so the destination directory is
> the one actually being changed by the operation:
> {code}
> copyFrom(Directory from, String src, String dest, IOContext context)
> {code}
> Besides fixing the order to make sense, adding it to the name might help
> prevent bugs like the current TrackingDirectoryWrapper impl (used by
> IndexWriter to track what files are used):
> {code}
> public void copy(Directory to, String src, String dest, IOContext context)
> throws IOException {
> createdFileNames.add(dest); // BUG!
> in.copy(to, src, dest, context);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6153) randomize stored fields/vectors index blocksize
[ https://issues.apache.org/jira/browse/LUCENE-6153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-6153. - Resolution: Fixed Fix Version/s: Trunk 5.0 > randomize stored fields/vectors index blocksize > --- > > Key: LUCENE-6153 > URL: https://issues.apache.org/jira/browse/LUCENE-6153 > Project: Lucene - Core > Issue Type: Test >Reporter: Robert Muir > Fix For: 5.0, Trunk > > Attachments: LUCENE-6153.patch > > > the Compressing impls compress documents into chunks. We then record index > data for every N chunks, which is binary searched to find the start of the > chunk. today this is always 1024. > This means to test the stored fields index well, we need to index thousands > and thousands of documents. But if we randomize the parameter, we can test it > more effectively by setting it to very low values (e.g. 5) in tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6153) randomize stored fields/vectors index blocksize
[ https://issues.apache.org/jira/browse/LUCENE-6153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262570#comment-14262570 ] ASF subversion and git services commented on LUCENE-6153: - Commit 1648850 from [~rcmuir] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1648850 ] LUCENE-6153: randomize stored fields/vectors index blocksize > randomize stored fields/vectors index blocksize > --- > > Key: LUCENE-6153 > URL: https://issues.apache.org/jira/browse/LUCENE-6153 > Project: Lucene - Core > Issue Type: Test >Reporter: Robert Muir > Fix For: 5.0, Trunk > > Attachments: LUCENE-6153.patch > > > the Compressing impls compress documents into chunks. We then record index > data for every N chunks, which is binary searched to find the start of the > chunk. today this is always 1024. > This means to test the stored fields index well, we need to index thousands > and thousands of documents. But if we randomize the parameter, we can test it > more effectively by setting it to very low values (e.g. 5) in tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6153) randomize stored fields/vectors index blocksize
[ https://issues.apache.org/jira/browse/LUCENE-6153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262567#comment-14262567 ] ASF subversion and git services commented on LUCENE-6153: - Commit 1648849 from [~rcmuir] in branch 'dev/trunk' [ https://svn.apache.org/r1648849 ] LUCENE-6153: randomize stored fields/vectors index blocksize > randomize stored fields/vectors index blocksize > --- > > Key: LUCENE-6153 > URL: https://issues.apache.org/jira/browse/LUCENE-6153 > Project: Lucene - Core > Issue Type: Test >Reporter: Robert Muir > Attachments: LUCENE-6153.patch > > > the Compressing impls compress documents into chunks. We then record index > data for every N chunks, which is binary searched to find the start of the > chunk. today this is always 1024. > This means to test the stored fields index well, we need to index thousands > and thousands of documents. But if we randomize the parameter, we can test it > more effectively by setting it to very low values (e.g. 5) in tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6787) API to manage blobs in Solr
[
https://issues.apache.org/jira/browse/SOLR-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262565#comment-14262565
]
ASF subversion and git services commented on SOLR-6787:
---
Commit 1648848 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1648848 ]
SOLR-6787 changed the schema of blob store. now, the id is blobName/version and
not the md5
> API to manage blobs in Solr
>
>
> Key: SOLR-6787
> URL: https://issues.apache.org/jira/browse/SOLR-6787
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6787.patch, SOLR-6787.patch
>
>
> A special collection called .system needs to be created by the user to
> store/manage blobs. The schema/solrconfig of that collection need to be
> automatically supplied by the system so that there are no errors
> APIs need to be created to manage the content of that collection
> {code}
> #create your .system collection first
> http://localhost:8983/solr/admin/collections?action=CREATE&name=.system&replicationFactor=2
> #The config for this collection is automatically created . numShards for this
> collection is hardcoded to 1
> #create a new jar or add a new version of a jar
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @mycomponent.jar http://localhost:8983/solr/.system/blob/mycomponent
> # GET on the end point would give a list of jars and other details
> curl http://localhost:8983/solr/.system/blob
> # GET on the end point with jar name would give details of various versions
> of the available jars
> curl http://localhost:8983/solr/.system/blob/mycomponent
> # GET on the end point with jar name and version with a wt=filestream to get
> the actual file
> curl http://localhost:8983/solr/.system/blob/mycomponent/1?wt=filestream >
> mycomponent.1.jar
> # GET on the end point with jar name and wt=filestream to get the latest
> version of the file
> curl http://localhost:8983/solr/.system/blob/mycomponent?wt=filestream >
> mycomponent.jar
> {code}
> Please note that the jars are never deleted. a new version is added to the
> system everytime a new jar is posted for the name. You must use the standard
> delete commands to delete the old entries
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6770) Add/edit param sets and use them in Requests
[
https://issues.apache.org/jira/browse/SOLR-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-6770:
-
Fix Version/s: 5.0
> Add/edit param sets and use them in Requests
>
>
> Key: SOLR-6770
> URL: https://issues.apache.org/jira/browse/SOLR-6770
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6770.patch, SOLR-6770.patch, SOLR-6770.patch
>
>
> Make it possible to define paramsets and use them directly in requests
> example
> {code}
> curl http://localhost:8983/solr/collection1/config/params -H
> 'Content-type:application/json' -d '{
> "set" : {"x": {
> "a":"A val",
> "b": "B val"}
>},
> "set" : {"y": {
>"x":"X val",
>"Y": "Y val"}
>},
> "update" : {"y": {
>"x":"X val modified"}
>},
> "delete" : "z"
> }'
> #do a GET to view all the configured params
> curl http://localhost:8983/solr/collection1/config/params
> #or GET with a specific name to get only one set of params
> curl http://localhost:8983/solr/collection1/config/params/x
> {code}
> This data will be stored in conf/params.json
> This is used requesttime and adding/editing params will not result in core
> reload and it will have no impact on the performance
> example usage http://localhost/solr/collection/select?useParams=x,y
> or it can be directly configured with a request handler as follows
> {code}
>
> {code}
> {{useParams}} specified in request overrides the one specified in
> {{requestHandler}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6770) Add/edit param sets and use them in Requests
[
https://issues.apache.org/jira/browse/SOLR-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262561#comment-14262561
]
ASF subversion and git services commented on SOLR-6770:
---
Commit 1648847 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1648847 ]
SOLR-6770: Add/edit param sets and use them in Requests
> Add/edit param sets and use them in Requests
>
>
> Key: SOLR-6770
> URL: https://issues.apache.org/jira/browse/SOLR-6770
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6770.patch, SOLR-6770.patch, SOLR-6770.patch
>
>
> Make it possible to define paramsets and use them directly in requests
> example
> {code}
> curl http://localhost:8983/solr/collection1/config/params -H
> 'Content-type:application/json' -d '{
> "set" : {"x": {
> "a":"A val",
> "b": "B val"}
>},
> "set" : {"y": {
>"x":"X val",
>"Y": "Y val"}
>},
> "update" : {"y": {
>"x":"X val modified"}
>},
> "delete" : "z"
> }'
> #do a GET to view all the configured params
> curl http://localhost:8983/solr/collection1/config/params
> #or GET with a specific name to get only one set of params
> curl http://localhost:8983/solr/collection1/config/params/x
> {code}
> This data will be stored in conf/params.json
> This is used requesttime and adding/editing params will not result in core
> reload and it will have no impact on the performance
> example usage http://localhost/solr/collection/select?useParams=x,y
> or it can be directly configured with a request handler as follows
> {code}
>
> {code}
> {{useParams}} specified in request overrides the one specified in
> {{requestHandler}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6137) RussianLightStemmer incorrectly handles the words ending with 'ее'
[ https://issues.apache.org/jira/browse/LUCENE-6137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262559#comment-14262559 ] Alexander Sofronov commented on LUCENE-6137: Yes, I sent link to this issue. My opinion is that comparative forms should be stemmed also. Please note that comparative forms in Russian can have not only "ее" endings, but also "ий", "ей" and some other that listed in RussianLightStemmer. Also, please take a look and Perl version of Russian light stemmer (http://members.unine.ch/jacques.savoy/clef/russianStemmerPerl.txt) which handles "ее" and "ие" endings properly. > RussianLightStemmer incorrectly handles the words ending with 'ее' > -- > > Key: LUCENE-6137 > URL: https://issues.apache.org/jira/browse/LUCENE-6137 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 4.10.2 >Reporter: Alexander Sofronov > Attachments: LUCENE-6137.patch > > > Consider the forms of Russian word "синий" and the result returned by > RussianLightStemmer: > синий -> син > синяя -> син > синее -> сине > синие -> син > I think the correct result should be: > синий -> син > синяя -> син > синее -> син > синие -> син -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_40-ea-b09) - Build # 4526 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4526/ Java: 64bit/jdk1.8.0_40-ea-b09 -XX:+UseCompressedOops -XX:+UseG1GC (asserts: false) 1 tests failed. FAILED: org.apache.solr.cloud.DeleteReplicaTest.testDistribSearch Error Message: Should have had a good message here Stack Trace: java.lang.AssertionError: Should have had a good message here at __randomizedtesting.SeedInfo.seed([DE0AD8B6011D:5FEC56AE775F6121]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.DeleteReplicaTest.deleteLiveReplicaTest(DeleteReplicaTest.java:138) at org.apache.solr.cloud.DeleteReplicaTest.doTest(DeleteReplicaTest.java:89) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868) at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.jav
[jira] [Resolved] (SOLR-6654) add a standard way to listen to config changes in cloud mode
[
https://issues.apache.org/jira/browse/SOLR-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-6654.
--
Resolution: Fixed
Fix Version/s: Trunk
fixed as a part of commit 1648689 for SOLR-6770
there are 2 methods {{SolrCore#addConfListener()}} and
{{SolrCore#removeConfListener()}}
> add a standard way to listen to config changes in cloud mode
>
>
> Key: SOLR-6654
> URL: https://issues.apache.org/jira/browse/SOLR-6654
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: Trunk
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6787) API to manage blobs in Solr
[
https://issues.apache.org/jira/browse/SOLR-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262542#comment-14262542
]
ASF subversion and git services commented on SOLR-6787:
---
Commit 1648836 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1648836 ]
SOLR-6787 changed the schema of blob store. now, the id is blobName/version and
not the md5
> API to manage blobs in Solr
>
>
> Key: SOLR-6787
> URL: https://issues.apache.org/jira/browse/SOLR-6787
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6787.patch, SOLR-6787.patch
>
>
> A special collection called .system needs to be created by the user to
> store/manage blobs. The schema/solrconfig of that collection need to be
> automatically supplied by the system so that there are no errors
> APIs need to be created to manage the content of that collection
> {code}
> #create your .system collection first
> http://localhost:8983/solr/admin/collections?action=CREATE&name=.system&replicationFactor=2
> #The config for this collection is automatically created . numShards for this
> collection is hardcoded to 1
> #create a new jar or add a new version of a jar
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @mycomponent.jar http://localhost:8983/solr/.system/blob/mycomponent
> # GET on the end point would give a list of jars and other details
> curl http://localhost:8983/solr/.system/blob
> # GET on the end point with jar name would give details of various versions
> of the available jars
> curl http://localhost:8983/solr/.system/blob/mycomponent
> # GET on the end point with jar name and version with a wt=filestream to get
> the actual file
> curl http://localhost:8983/solr/.system/blob/mycomponent/1?wt=filestream >
> mycomponent.1.jar
> # GET on the end point with jar name and wt=filestream to get the latest
> version of the file
> curl http://localhost:8983/solr/.system/blob/mycomponent?wt=filestream >
> mycomponent.jar
> {code}
> Please note that the jars are never deleted. a new version is added to the
> system everytime a new jar is posted for the name. You must use the standard
> delete commands to delete the old entries
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6792) cleanup solrconfig.xml files by removing implicit plugins
[ https://issues.apache.org/jira/browse/SOLR-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262540#comment-14262540 ] Noble Paul commented on SOLR-6792: -- [~romseygeek] I'm not sure . What would you recommend? > cleanup solrconfig.xml files by removing implicit plugins > - > > Key: SOLR-6792 > URL: https://issues.apache.org/jira/browse/SOLR-6792 > Project: Solr > Issue Type: Bug >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 5.0, Trunk > > Attachments: SOLR-6792.patch > > > /replication , /get , /update, /admin/ are registered implicitly for each > core. No need to specify them from solrconfig.xml if nothing custom needs to > be added -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6119) Add auto-io-throttle to ConcurrentMergeScheduler
[ https://issues.apache.org/jira/browse/LUCENE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-6119: --- Summary: Add auto-io-throttle to ConcurrentMergeScheduler (was: Add AdaptiveRateLimitedDirectoryWrapper) > Add auto-io-throttle to ConcurrentMergeScheduler > > > Key: LUCENE-6119 > URL: https://issues.apache.org/jira/browse/LUCENE-6119 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-6119.patch, LUCENE-6119.patch, LUCENE-6119.patch, > LUCENE-6119.patch > > > This method returns number of "incoming" bytes IW has written since it > was opened, excluding merging. > It tracks flushed segments, new commits (segments_N), incoming > files/segments by addIndexes, newly written live docs / doc values > updates files. > It's an easy statistic for IW to track and should be useful to help > applications more intelligently set defaults for IO throttling > (RateLimiter). > For example, an application that does hardly any indexing but finally > triggered a large merge can afford to heavily throttle that large > merge so it won't interfere with ongoing searches. > But an application that's causing IW to write new bytes at 50 MB/sec > must set a correspondingly higher IO throttling otherwise merges will > clearly fall behind. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6119) Add AdaptiveRateLimitedDirectoryWrapper
[ https://issues.apache.org/jira/browse/LUCENE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-6119: --- Attachment: LUCENE-6119.patch New patch... I think it's close. This adds "enable/disableAutoIOThrottle" methods to CMS, to have CMS pick a reasonable IO throttle over time so merges don't fall behind but also don't suck up all available IO. It's a live setting, and default is on. CMS.getIORateLimitMBPerSec returns the current auto-IO-rate. All "merge abort checks" are gone and instead handled by the per-merge rate limiter that IW sets up for each merge. This gives merge schedulers "io nice"-like control over each merge thread. Setting the right IO throttle is a fun control problem (see http://en.wikipedia.org/wiki/Control_theory), much like the fan in your laptop that changes its speed depending on internal temperature, or a factory that must add more workers depending on incoming jobs. I first tried "open loop" control, trying to set the rate based on indexing rate or incoming merges rate, but that doesn't work very well since there are many variables (e.g. CFS on or off) that affect required MB/sec writing. So then I switched to a simplistic feedback control: when a merge arrives, if another merge that's "close" to that same size is still running, we are falling behind and we aggressively (+20%) increase the IO throttle. Else, if there is a prior backlog still, leave the rate unchanged. Else, we decrease it. In my various tests of "tiny flushed segs" vs "big flushed segs", NRT reopens vs no, CFS or not, 1 2 or 3 merge threads, this approach seems to work well. I haven't yet tested on spinning disks though ... will have to wait until I'm back home ... somehow my beast box died while I'm on vacation! I think fsck must be waiting for me on the console :( Forced merges have their own separate throttle (defaults to unlimited). I think it's important CMS *not* have min/max MB/sec throttle control: I think this just invites disaster when apps set them to inappropriate values (but I added a protected CMS method "escape hatch" so a subclass can override the control logic). I also removed RateLimitedDirectoryWrapper: it's too simplistic and too dangerous. Finally I cleaned a few things up and improved verbose infoStream logging so we can see more stats for each merge. > Add AdaptiveRateLimitedDirectoryWrapper > --- > > Key: LUCENE-6119 > URL: https://issues.apache.org/jira/browse/LUCENE-6119 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-6119.patch, LUCENE-6119.patch, LUCENE-6119.patch, > LUCENE-6119.patch > > > This method returns number of "incoming" bytes IW has written since it > was opened, excluding merging. > It tracks flushed segments, new commits (segments_N), incoming > files/segments by addIndexes, newly written live docs / doc values > updates files. > It's an easy statistic for IW to track and should be useful to help > applications more intelligently set defaults for IO throttling > (RateLimiter). > For example, an application that does hardly any indexing but finally > triggered a large merge can afford to heavily throttle that large > merge so it won't interfere with ongoing searches. > But an application that's causing IW to write new bytes at 50 MB/sec > must set a correspondingly higher IO throttling otherwise merges will > clearly fall behind. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6154) nuke FilterDirectory.unwrap or make package-private
[ https://issues.apache.org/jira/browse/LUCENE-6154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262529#comment-14262529 ] Michael McCandless commented on LUCENE-6154: OK I agree: this method is dangerous, so we should remove it. ES can do this on its own. Fortunately it has not been released yet: I added it in LUCENE-6099. > nuke FilterDirectory.unwrap or make package-private > --- > > Key: LUCENE-6154 > URL: https://issues.apache.org/jira/browse/LUCENE-6154 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > > As Uwe points out, this is dangerous. The only thing using it is its test: > TestFilterDirectory.testUnwrap() and IOUtils.spins(). > If this method is implemented in some other way, we could remove it. > otherwise maybe it can be package-private. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6150) Remove staleFiles set and onIndexOutputClosed from FSDirectory
[ https://issues.apache.org/jira/browse/LUCENE-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-6150: -- Summary: Remove staleFiles set and onIndexOutputClosed from FSDirectory (was: Remove staleFiles set from FSDirectory) > Remove staleFiles set and onIndexOutputClosed from FSDirectory > -- > > Key: LUCENE-6150 > URL: https://issues.apache.org/jira/browse/LUCENE-6150 > Project: Lucene - Core > Issue Type: Task > Components: core/store >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 5.0, Trunk > > Attachments: LUCENE-6150.patch > > > Hi, > the "hack" to keep track of files written to in FSDirectory, to filter them > when calling sync is heavily broken. [~mikemccand] already opened an issue, > which was abandoned then. > In fact handling this in FSDirectory is a hack and broken! If IndexWriter is > itsself not able to correctly handle tracking the files, it is also his > repsonsibilty to do this. We already have a class that can do this: > TrackingDirectoryWrapper. IndexWriter should use an instance of this class to > track those stale files (until the problem is solved). > I would like to keep FSDirectory clean from this, especially, as this is > broken anyways: If somebody has another directory impl like HDFS or > Infinispan, the problem still persists. The base directory should throw an > IOException if trying to sync a file that does not exist! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6150) Remove staleFiles set from FSDirectory
[ https://issues.apache.org/jira/browse/LUCENE-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-6150. --- Resolution: Fixed > Remove staleFiles set from FSDirectory > -- > > Key: LUCENE-6150 > URL: https://issues.apache.org/jira/browse/LUCENE-6150 > Project: Lucene - Core > Issue Type: Task > Components: core/store >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 5.0, Trunk > > Attachments: LUCENE-6150.patch > > > Hi, > the "hack" to keep track of files written to in FSDirectory, to filter them > when calling sync is heavily broken. [~mikemccand] already opened an issue, > which was abandoned then. > In fact handling this in FSDirectory is a hack and broken! If IndexWriter is > itsself not able to correctly handle tracking the files, it is also his > repsonsibilty to do this. We already have a class that can do this: > TrackingDirectoryWrapper. IndexWriter should use an instance of this class to > track those stale files (until the problem is solved). > I would like to keep FSDirectory clean from this, especially, as this is > broken anyways: If somebody has another directory impl like HDFS or > Infinispan, the problem still persists. The base directory should throw an > IOException if trying to sync a file that does not exist! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6150) Remove staleFiles set from FSDirectory
[ https://issues.apache.org/jira/browse/LUCENE-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262528#comment-14262528 ] ASF subversion and git services commented on LUCENE-6150: - Commit 1648813 from [~thetaphi] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1648813 ] Merged revision(s) 1648812 from lucene/dev/trunk: LUCENE-6150: Remove staleFiles set and onIndexOutputClosed() from FSDirectory > Remove staleFiles set from FSDirectory > -- > > Key: LUCENE-6150 > URL: https://issues.apache.org/jira/browse/LUCENE-6150 > Project: Lucene - Core > Issue Type: Task > Components: core/store >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 5.0, Trunk > > Attachments: LUCENE-6150.patch > > > Hi, > the "hack" to keep track of files written to in FSDirectory, to filter them > when calling sync is heavily broken. [~mikemccand] already opened an issue, > which was abandoned then. > In fact handling this in FSDirectory is a hack and broken! If IndexWriter is > itsself not able to correctly handle tracking the files, it is also his > repsonsibilty to do this. We already have a class that can do this: > TrackingDirectoryWrapper. IndexWriter should use an instance of this class to > track those stale files (until the problem is solved). > I would like to keep FSDirectory clean from this, especially, as this is > broken anyways: If somebody has another directory impl like HDFS or > Infinispan, the problem still persists. The base directory should throw an > IOException if trying to sync a file that does not exist! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6150) Remove staleFiles set from FSDirectory
[ https://issues.apache.org/jira/browse/LUCENE-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262527#comment-14262527 ] ASF subversion and git services commented on LUCENE-6150: - Commit 1648812 from [~thetaphi] in branch 'dev/trunk' [ https://svn.apache.org/r1648812 ] LUCENE-6150: Remove staleFiles set and onIndexOutputClosed() from FSDirectory > Remove staleFiles set from FSDirectory > -- > > Key: LUCENE-6150 > URL: https://issues.apache.org/jira/browse/LUCENE-6150 > Project: Lucene - Core > Issue Type: Task > Components: core/store >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 5.0, Trunk > > Attachments: LUCENE-6150.patch > > > Hi, > the "hack" to keep track of files written to in FSDirectory, to filter them > when calling sync is heavily broken. [~mikemccand] already opened an issue, > which was abandoned then. > In fact handling this in FSDirectory is a hack and broken! If IndexWriter is > itsself not able to correctly handle tracking the files, it is also his > repsonsibilty to do this. We already have a class that can do this: > TrackingDirectoryWrapper. IndexWriter should use an instance of this class to > track those stale files (until the problem is solved). > I would like to keep FSDirectory clean from this, especially, as this is > broken anyways: If somebody has another directory impl like HDFS or > Infinispan, the problem still persists. The base directory should throw an > IOException if trying to sync a file that does not exist! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6150) Remove staleFiles set from FSDirectory
[ https://issues.apache.org/jira/browse/LUCENE-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262526#comment-14262526 ] Uwe Schindler commented on LUCENE-6150: --- Thanks Mike for confirmation! I will commit this and we will se the impact in your nightly benchmark, so I think we are fine. If it is really a problem, I would like to "simplify" the tracking (remove the onIndexOutputClosed callback - that was the most annoying thing, because it makes the API horrible, because the tracking is not hidden). In fact, the tracking on close is not needed here. Its enough to simply add the filename to the set while opeining the output, then it can be completely private to the impl in FSDirectory. > Remove staleFiles set from FSDirectory > -- > > Key: LUCENE-6150 > URL: https://issues.apache.org/jira/browse/LUCENE-6150 > Project: Lucene - Core > Issue Type: Task > Components: core/store >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 5.0, Trunk > > Attachments: LUCENE-6150.patch > > > Hi, > the "hack" to keep track of files written to in FSDirectory, to filter them > when calling sync is heavily broken. [~mikemccand] already opened an issue, > which was abandoned then. > In fact handling this in FSDirectory is a hack and broken! If IndexWriter is > itsself not able to correctly handle tracking the files, it is also his > repsonsibilty to do this. We already have a class that can do this: > TrackingDirectoryWrapper. IndexWriter should use an instance of this class to > track those stale files (until the problem is solved). > I would like to keep FSDirectory clean from this, especially, as this is > broken anyways: If somebody has another directory impl like HDFS or > Infinispan, the problem still persists. The base directory should throw an > IOException if trying to sync a file that does not exist! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6150) Remove staleFiles set from FSDirectory
[ https://issues.apache.org/jira/browse/LUCENE-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262524#comment-14262524 ] Michael McCandless commented on LUCENE-6150: +1 to simply remove this tracking ([~thetaphi]'s patch) entirely! fsync really should be fast if the file was already forced to disk. > Remove staleFiles set from FSDirectory > -- > > Key: LUCENE-6150 > URL: https://issues.apache.org/jira/browse/LUCENE-6150 > Project: Lucene - Core > Issue Type: Task > Components: core/store >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 5.0, Trunk > > Attachments: LUCENE-6150.patch > > > Hi, > the "hack" to keep track of files written to in FSDirectory, to filter them > when calling sync is heavily broken. [~mikemccand] already opened an issue, > which was abandoned then. > In fact handling this in FSDirectory is a hack and broken! If IndexWriter is > itsself not able to correctly handle tracking the files, it is also his > repsonsibilty to do this. We already have a class that can do this: > TrackingDirectoryWrapper. IndexWriter should use an instance of this class to > track those stale files (until the problem is solved). > I would like to keep FSDirectory clean from this, especially, as this is > broken anyways: If somebody has another directory impl like HDFS or > Infinispan, the problem still persists. The base directory should throw an > IOException if trying to sync a file that does not exist! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2409 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2409/ All tests passed Build Log: [...truncated 59020 lines...] BUILD FAILED /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/build.xml:529: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/build.xml:83: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/solr/build.xml:563: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/solr/build.xml:538: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/common-build.xml:2502: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:196) at java.net.SocketInputStream.read(SocketInputStream.java:122) at sun.security.ssl.InputRecord.readFully(InputRecord.java:442) at sun.security.ssl.InputRecord.readV3Record(InputRecord.java:554) at sun.security.ssl.InputRecord.read(InputRecord.java:509) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927) at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:884) at sun.security.ssl.AppInputStream.read(AppInputStream.java:102) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read1(BufferedInputStream.java:275) at java.io.BufferedInputStream.read(BufferedInputStream.java:334) at sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:552) at sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:609) at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:696) at java.io.FilterInputStream.read(FilterInputStream.java:133) at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:3053) at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:3047) at org.apache.tools.ant.taskdefs.Get$GetThread.downloadFile(Get.java:745) at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:586) at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569) Total time: 560 minutes 39 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Sending artifact delta relative to Lucene-Solr-Tests-5.x-Java7 #2405 Archived 1 artifacts Archive block size is 32768 Received 0 blocks and 464 bytes Compression is 0.0% Took 67 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
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_40-ea-b09) - Build # 11832 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11832/ Java: 64bit/jdk1.8.0_40-ea-b09 -XX:-UseCompressedOops -XX:+UseG1GC (asserts: true) 1 tests failed. FAILED: org.apache.solr.update.AutoCommitTest.testCommitWithin Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([D1825955A14EFCC:B7CA4AEDD93A01D9]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:730) at org.apache.solr.update.AutoCommitTest.testCommitWithin(AutoCommitTest.java:319) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound=1] xml response was: 00 request was:q=id:529&qt=standard&start=0&rows=20&v
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2028 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2028/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC (asserts: true) 2 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([ACA3BF961C3082C4]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeySafeLeaderTest Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([ACA3BF961C3082C4]:0) Build Log: [...truncated 9425 lines...] [junit4] Suite: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest [junit4] 2> Creating dataDir: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/J0/temp/solr.cloud.ChaosMonkeySafeLeaderTest-ACA3BF961C3082C4-001/init-core-data-001 [junit4] 2> 2915835 T14355 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl (false) and clientAuth (false) [junit4] 2> 2915836 T14355 oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext system property: / [junit4] 2> 2915852 T14355 oas.SolrTestCaseJ4.setUp ###Starting testDistribSearch [junit4] 2> 2915853 T14355 oasc.ZkTestServer.run STARTING ZK TEST SERVER [junit4] 1> client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 2915855 T14356 oasc.ZkTestServer$ZKServerMain.runFromConfig Starting server [junit4] 2> 2915956 T14355 oasc.ZkTestServer.run start zk server on port:53946 [junit4] 2> 2915957 T14355 oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default ZkCredentialsProvider [junit4] 2> 2915958 T14355 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2> 2915965 T14363 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@52e17cd5 name:ZooKeeperConnection Watcher:127.0.0.1:53946 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 2915966 T14355 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2> 2915967 T14355 oascc.SolrZkClient.createZkACLProvider Using default ZkACLProvider [junit4] 2> 2915967 T14355 oascc.SolrZkClient.makePath makePath: /solr [junit4] 2> 2915993 T14355 oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default ZkCredentialsProvider [junit4] 2> 2915995 T14355 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2> 2916002 T14366 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@4bb87f7f name:ZooKeeperConnection Watcher:127.0.0.1:53946/solr got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 2916003 T14355 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2> 2916003 T14355 oascc.SolrZkClient.createZkACLProvider Using default ZkACLProvider [junit4] 2> 2916004 T14355 oascc.SolrZkClient.makePath makePath: /collections/collection1 [junit4] 2> 2916019 T14355 oascc.SolrZkClient.makePath makePath: /collections/collection1/shards [junit4] 2> 2916030 T14355 oascc.SolrZkClient.makePath makePath: /collections/control_collection [junit4] 2> 2916041 T14355 oascc.SolrZkClient.makePath makePath: /collections/control_collection/shards [junit4] 2> 2916052 T14355 oasc.AbstractZkTestCase.putConfig put /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2> 2916054 T14355 oascc.SolrZkClient.makePath makePath: /configs/conf1/solrconfig.xml [junit4] 2> 2916068 T14355 oasc.AbstractZkTestCase.putConfig put /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/src/test-files/solr/collection1/conf/schema15.xml to /configs/conf1/schema.xml [junit4] 2> 2916069 T14355 oascc.SolrZkClient.makePath makePath: /configs/conf1/schema.xml [junit4] 2> 2916079 T14355 oasc.AbstractZkTestCase.putConfig put /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml to /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 2916080 T14355 oascc.SolrZkClient.makePath makePath: /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 2916090 T14355 oasc.AbstractZkTestCase.putConfig put /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/src/test-files/solr/collection1/conf/stopwords.txt to /configs/conf1/stopwords.txt [junit4] 2> 2916092 T14355 oascc.SolrZkClient.makePath makePath: /configs/conf1/stopwords.txt [junit4] 2> 2916101 T14355 oasc.AbstractZkTestCase.putC
[JENKINS] Lucene-Solr-4.10-Linux (64bit/jdk1.8.0_20) - Build # 199 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.10-Linux/199/ Java: 64bit/jdk1.8.0_20 -XX:-UseCompressedOops -XX:+UseParallelGC (asserts: false) All tests passed Build Log: [...truncated 47502 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.10-Linux/build.xml:474: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.10-Linux/build.xml:63: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.10-Linux/lucene/build.xml:212: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.10-Linux/lucene/build.xml:544: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.10-Linux/lucene/common-build.xml:2448: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:189) at java.net.SocketInputStream.read(SocketInputStream.java:121) at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) at sun.security.ssl.InputRecord.read(InputRecord.java:503) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:954) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1343) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153) at org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:660) at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:579) at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569) Total time: 106 minutes 16 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.8.0_20 -XX:-UseCompressedOops -XX:+UseParallelGC (asserts: false) 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
