[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 175 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/175/ 1 tests failed. FAILED: org.apache.solr.cloud.HttpPartitionWithTlogReplicasTest.test Error Message: Timeout waiting for state down of replica core_node4, current state active expected: but was: Stack Trace: java.lang.AssertionError: Timeout waiting for state down of replica core_node4, current state active expected: but was: at __randomizedtesting.SeedInfo.seed([A3290B824DD63D8A:2B7D3458E32A5072]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:118) at org.apache.solr.cloud.HttpPartitionTest.waitForState(HttpPartitionTest.java:326) at org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:233) at org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:135) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at
[jira] [Updated] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml
[
https://issues.apache.org/jira/browse/SOLR-13679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-13679:
Resolution: Fixed
Fix Version/s: 8.3
Status: Resolved (was: Patch Available)
> Different default Style for [explain] doctransformer registered in
> solrconfig.xml
> --
>
> Key: SOLR-13679
> URL: https://issues.apache.org/jira/browse/SOLR-13679
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Minor
> Fix For: 8.3
>
> Attachments: SOLR-13679.patch, SOLR-13679.patch
>
>
> Adding explain docTransformer via solrconfig.xml
> {code:java}
> class="org.apache.solr.response.transform.ExplainAugmenterFactory" />
> {code}
> Here, no style is specified. So, default style is used which is {{nl}}.
> ExplainDocTransformer is part of defaultFactories. So, user can use this
> without adding it in solrconfig.xml but when used this way, default style
> used is {{text}}
> Default style should be same in both cases. This behavior is same to
> registering ResponseWriters in solrconfig, if content-type is not overridden
> then, default content-type will used
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml
[
https://issues.apache.org/jira/browse/SOLR-13679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899775#comment-16899775
]
ASF subversion and git services commented on SOLR-13679:
Commit 6fc042dd6d2e3660d9e91fc5000204aef5957e28 in lucene-solr's branch
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6fc042d ]
SOLR-13679: move changes entry to bug fix section
> Different default Style for [explain] doctransformer registered in
> solrconfig.xml
> --
>
> Key: SOLR-13679
> URL: https://issues.apache.org/jira/browse/SOLR-13679
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13679.patch, SOLR-13679.patch
>
>
> Adding explain docTransformer via solrconfig.xml
> {code:java}
> class="org.apache.solr.response.transform.ExplainAugmenterFactory" />
> {code}
> Here, no style is specified. So, default style is used which is {{nl}}.
> ExplainDocTransformer is part of defaultFactories. So, user can use this
> without adding it in solrconfig.xml but when used this way, default style
> used is {{text}}
> Default style should be same in both cases. This behavior is same to
> registering ResponseWriters in solrconfig, if content-type is not overridden
> then, default content-type will used
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml
[
https://issues.apache.org/jira/browse/SOLR-13679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899772#comment-16899772
]
ASF subversion and git services commented on SOLR-13679:
Commit b4e49206edbfb4e9dd580739f1271cea18135bc4 in lucene-solr's branch
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b4e4920 ]
SOLR-13679:Fix default style of [explain] registered in solrconfig.xml
> Different default Style for [explain] doctransformer registered in
> solrconfig.xml
> --
>
> Key: SOLR-13679
> URL: https://issues.apache.org/jira/browse/SOLR-13679
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13679.patch, SOLR-13679.patch
>
>
> Adding explain docTransformer via solrconfig.xml
> {code:java}
> class="org.apache.solr.response.transform.ExplainAugmenterFactory" />
> {code}
> Here, no style is specified. So, default style is used which is {{nl}}.
> ExplainDocTransformer is part of defaultFactories. So, user can use this
> without adding it in solrconfig.xml but when used this way, default style
> used is {{text}}
> Default style should be same in both cases. This behavior is same to
> registering ResponseWriters in solrconfig, if content-type is not overridden
> then, default content-type will used
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12555) Replace try-fail-catch test patterns
[
https://issues.apache.org/jira/browse/SOLR-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-12555:
Resolution: Done
Status: Resolved (was: Patch Available)
As all the try-fail-catch are replaced with expectThrows(), closing this
> Replace try-fail-catch test patterns
>
>
> Key: SOLR-12555
> URL: https://issues.apache.org/jira/browse/SOLR-12555
> Project: Solr
> Issue Type: Test
> Components: Tests
>Affects Versions: 8.0
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-12555-sorted-by-package.txt, SOLR-12555.patch,
> SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch,
> SOLR-12555.txt
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> I recently added some test code through SOLR-12427 which used the following
> test anti-pattern:
> {code}
> try {
> actionExpectedToThrowException();
> fail("I expected this to throw an exception, but it didn't");
> catch (Exception e) {
> assertOnThrownException(e);
> }
> {code}
> Hoss (rightfully) objected that this should instead be written using the
> formulation below, which is clearer and more concise.
> {code}
> SolrException e = expectThrows(() -> {...});
> {code}
> We should remove many of these older formulations where it makes sense. Many
> of them were written before {{expectThrows}} was introduced, and having the
> old style assertions around makes it easier for them to continue creeping in.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml
[
https://issues.apache.org/jira/browse/SOLR-13679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899763#comment-16899763
]
ASF subversion and git services commented on SOLR-13679:
Commit 84a62a5d873516686c8d04529f37175af2fb7be0 in lucene-solr's branch
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=84a62a5 ]
SOLR-13679:Fix default style of [explain] registered in solrconfig.xml
> Different default Style for [explain] doctransformer registered in
> solrconfig.xml
> --
>
> Key: SOLR-13679
> URL: https://issues.apache.org/jira/browse/SOLR-13679
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13679.patch, SOLR-13679.patch
>
>
> Adding explain docTransformer via solrconfig.xml
> {code:java}
> class="org.apache.solr.response.transform.ExplainAugmenterFactory" />
> {code}
> Here, no style is specified. So, default style is used which is {{nl}}.
> ExplainDocTransformer is part of defaultFactories. So, user can use this
> without adding it in solrconfig.xml but when used this way, default style
> used is {{text}}
> Default style should be same in both cases. This behavior is same to
> registering ResponseWriters in solrconfig, if content-type is not overridden
> then, default content-type will used
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13676) Reduce log verbosity in TestDistributedGrouping using ignoreException
[
https://issues.apache.org/jira/browse/SOLR-13676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N resolved SOLR-13676.
-
Resolution: Done
Fix Version/s: 8.3
> Reduce log verbosity in TestDistributedGrouping using ignoreException
> -
>
> Key: SOLR-13676
> URL: https://issues.apache.org/jira/browse/SOLR-13676
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Diego Ceccarelli
>Assignee: Munendra S N
>Priority: Minor
> Fix For: 8.3
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> SOLR-13404 added a test that expects Solr to fail if grouping is called with
> {{group.offset < 0}}. When the test runs it succeeds but the whole stack
> trace is printed out in the logs. This small patch avoid the stack trace by
> using {{ignoreException}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13676) Reduce log verbosity in TestDistributedGrouping using ignoreException
[
https://issues.apache.org/jira/browse/SOLR-13676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899755#comment-16899755
]
ASF subversion and git services commented on SOLR-13676:
Commit 696e752be62f3e00b4b59675b544d0245899f782 in lucene-solr's branch
refs/heads/branch_8x from Diego
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=696e752 ]
SOLR-13676: Reduce log verbosity in TestDistributedGrouping (#819)
* SOLR-13676: Reduce log verbosity in TestDistributedGrouping using
ignoreException
* Code review
* Remove Assert
> Reduce log verbosity in TestDistributedGrouping using ignoreException
> -
>
> Key: SOLR-13676
> URL: https://issues.apache.org/jira/browse/SOLR-13676
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Diego Ceccarelli
>Assignee: Munendra S N
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> SOLR-13404 added a test that expects Solr to fail if grouping is called with
> {{group.offset < 0}}. When the test runs it succeeds but the whole stack
> trace is printed out in the logs. This small patch avoid the stack trace by
> using {{ignoreException}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13676) Reduce log verbosity in TestDistributedGrouping using ignoreException
[
https://issues.apache.org/jira/browse/SOLR-13676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899754#comment-16899754
]
ASF subversion and git services commented on SOLR-13676:
Commit 696e752be62f3e00b4b59675b544d0245899f782 in lucene-solr's branch
refs/heads/branch_8x from Diego
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=696e752 ]
SOLR-13676: Reduce log verbosity in TestDistributedGrouping (#819)
* SOLR-13676: Reduce log verbosity in TestDistributedGrouping using
ignoreException
* Code review
* Remove Assert
> Reduce log verbosity in TestDistributedGrouping using ignoreException
> -
>
> Key: SOLR-13676
> URL: https://issues.apache.org/jira/browse/SOLR-13676
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Diego Ceccarelli
>Assignee: Munendra S N
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> SOLR-13404 added a test that expects Solr to fail if grouping is called with
> {{group.offset < 0}}. When the test runs it succeeds but the whole stack
> trace is printed out in the logs. This small patch avoid the stack trace by
> using {{ignoreException}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13680) Close Resources Properly
[ https://issues.apache.org/jira/browse/SOLR-13680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N updated SOLR-13680: Status: Patch Available (was: Open) > Close Resources Properly > > > Key: SOLR-13680 > URL: https://issues.apache.org/jira/browse/SOLR-13680 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.2 >Reporter: Furkan KAMACI >Assignee: Munendra S N >Priority: Major > Fix For: 8.3 > > Time Spent: 10m > Remaining Estimate: 0h > > Files, streams or connections which implements Closeable or AutoCloseable > interface should be closed after use. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13680) Close Resources Properly
[ https://issues.apache.org/jira/browse/SOLR-13680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N reassigned SOLR-13680: --- Assignee: Munendra S N > Close Resources Properly > > > Key: SOLR-13680 > URL: https://issues.apache.org/jira/browse/SOLR-13680 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.2 >Reporter: Furkan KAMACI >Assignee: Munendra S N >Priority: Major > Fix For: 8.3 > > Time Spent: 10m > Remaining Estimate: 0h > > Files, streams or connections which implements Closeable or AutoCloseable > interface should be closed after use. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] munendrasn closed pull request #561: SOLR-13215 Upgrade dropwizard metrics to 4.0.5.
munendrasn closed pull request #561: SOLR-13215 Upgrade dropwizard metrics to 4.0.5. URL: https://github.com/apache/lucene-solr/pull/561 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13676) Reduce log verbosity in TestDistributedGrouping using ignoreException
[
https://issues.apache.org/jira/browse/SOLR-13676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899752#comment-16899752
]
ASF subversion and git services commented on SOLR-13676:
Commit 751e64651cd612a78842bf652bf9a3b77322fc40 in lucene-solr's branch
refs/heads/master from Diego
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=751e646 ]
SOLR-13676: Reduce log verbosity in TestDistributedGrouping (#819)
* SOLR-13676: Reduce log verbosity in TestDistributedGrouping using
ignoreException
* Code review
* Remove Assert
> Reduce log verbosity in TestDistributedGrouping using ignoreException
> -
>
> Key: SOLR-13676
> URL: https://issues.apache.org/jira/browse/SOLR-13676
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Diego Ceccarelli
>Assignee: Munendra S N
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> SOLR-13404 added a test that expects Solr to fail if grouping is called with
> {{group.offset < 0}}. When the test runs it succeeds but the whole stack
> trace is printed out in the logs. This small patch avoid the stack trace by
> using {{ignoreException}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] munendrasn merged pull request #819: SOLR-13676: Reduce log verbosity in TestDistributedGrouping
munendrasn merged pull request #819: SOLR-13676: Reduce log verbosity in TestDistributedGrouping URL: https://github.com/apache/lucene-solr/pull/819 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13676) Reduce log verbosity in TestDistributedGrouping using ignoreException
[
https://issues.apache.org/jira/browse/SOLR-13676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899751#comment-16899751
]
ASF subversion and git services commented on SOLR-13676:
Commit 751e64651cd612a78842bf652bf9a3b77322fc40 in lucene-solr's branch
refs/heads/master from Diego
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=751e646 ]
SOLR-13676: Reduce log verbosity in TestDistributedGrouping (#819)
* SOLR-13676: Reduce log verbosity in TestDistributedGrouping using
ignoreException
* Code review
* Remove Assert
> Reduce log verbosity in TestDistributedGrouping using ignoreException
> -
>
> Key: SOLR-13676
> URL: https://issues.apache.org/jira/browse/SOLR-13676
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Diego Ceccarelli
>Assignee: Munendra S N
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> SOLR-13404 added a test that expects Solr to fail if grouping is called with
> {{group.offset < 0}}. When the test runs it succeeds but the whole stack
> trace is printed out in the logs. This small patch avoid the stack trace by
> using {{ignoreException}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 3496 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3496/ 1 tests failed. FAILED: org.apache.solr.cloud.HttpPartitionTest.test Error Message: Timeout occurred while waiting response from server at: http://127.0.0.1:41541/z Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: http://127.0.0.1:41541/z at __randomizedtesting.SeedInfo.seed([4B9BFC59D8E42A4E:C3CFC383761847B6]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:338) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1080) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1920 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1920/ No tests ran. Build Log: [...truncated 25 lines...] ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... 4 more java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[JENKINS] Lucene-Solr-8.2-Linux (64bit/jdk-12.0.1) - Build # 520 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.2-Linux/520/ Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 7 tests failed. FAILED: org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica Error Message: Timeout occurred while waiting response from server at: https://127.0.0.1:32773/solr Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: https://127.0.0.1:32773/solr at __randomizedtesting.SeedInfo.seed([7E848D7380020B88:1492ECA3E8F04142]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:384) at org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:256) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at
[GitHub] [lucene-solr] kamaci opened a new pull request #822: SOLR-13680 Auto closed resources after use which implements Closeable or AutoCloseable interface.
kamaci opened a new pull request #822: SOLR-13680 Auto closed resources after use which implements Closeable or AutoCloseable interface. URL: https://github.com/apache/lucene-solr/pull/822 # Description Files, streams or connections which implements Closeable or AutoCloseable interface should be closed after use. # Solution Auto closed resources after use which implements Closeable or AutoCloseable interface. # Tests No need to write extra tests. Existing tests should not fail after this implementation. # Checklist Please review the following and check all that apply: - [X] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [X] I have created a Jira issue and added the issue ID to my pull request title. - [X] I am authorized to contribute this code to the ASF and have removed any code I do not have a license to distribute. - [X] I have developed this patch against the `master` branch. - [X] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [X] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13680) Close Resources Properly
Furkan KAMACI created SOLR-13680: Summary: Close Resources Properly Key: SOLR-13680 URL: https://issues.apache.org/jira/browse/SOLR-13680 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 8.2 Reporter: Furkan KAMACI Fix For: 8.3 Files, streams or connections which implements Closeable or AutoCloseable interface should be closed after use. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13667) Add upper, lower, trim and split Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-13667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899699#comment-16899699 ] ASF subversion and git services commented on SOLR-13667: Commit ee0fd492444907de763183214d69df11e3284d83 in lucene-solr's branch refs/heads/SOLR-13105-visual from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ee0fd49 ] SOLR-13667: Fix precommit > Add upper, lower, trim and split Stream Evaluators > -- > > Key: SOLR-13667 > URL: https://issues.apache.org/jira/browse/SOLR-13667 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: streaming expressions >Reporter: Joel Bernstein >Priority: Major > Attachments: SOLR-13667.patch, SOLR-13667.patch > > > The upper and lower Stream Evaluators will convert strings to upper and lower > case. The trim Stream Evaluator will trim whitespace from strings and the > split Stream Evaluator will split a string by a delimiter regex. > These functions will operate on both strings and lists of strings. These are > useful functions for cleaning data during the loading process. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8906) Lucene50PostingsReader.postings() casts BlockTermState param to private IntBlockTermState
[ https://issues.apache.org/jira/browse/LUCENE-8906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899696#comment-16899696 ] ASF subversion and git services commented on LUCENE-8906: - Commit 52b5ec8068861d3724c83f63142105b7294cceef in lucene-solr's branch refs/heads/SOLR-13105-visual from Bruno Roustant [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=52b5ec8 ] LUCENE-8906: Lucene50PostingsFormat.IntBlockTermState becomes public > Lucene50PostingsReader.postings() casts BlockTermState param to private > IntBlockTermState > - > > Key: LUCENE-8906 > URL: https://issues.apache.org/jira/browse/LUCENE-8906 > Project: Lucene - Core > Issue Type: Improvement > Components: core/codecs >Reporter: Bruno Roustant >Assignee: David Smiley >Priority: Major > Fix For: 8.3 > > Time Spent: 40m > Remaining Estimate: 0h > > Lucene50PostingsReader is the public API that offers the postings() method to > read the postings. Any PostingFormat can use it (as well as > Lucene50PostingsWriter) to read/write postings. > But the postings() method asks for a (public) BlockTermState param which is > internally cast to the private IntBlockTermState. This BlockTermState is > provided by Lucene50PostingsReader.newTermState(). > public PostingsEnum postings(FieldInfo fieldInfo, BlockTermState termState, > PostingsEnum reuse, int flags) > This actually makes impossible to a custom PostingFormat customizing the > Block file structure to use this postings() method by providing their > (Int)BlockTermState, because they cannot access the FP fields of the > IntBlockTermState returned by PostingsReaderBase.newTermState(). > Proposed change: > * Either make IntBlockTermState public, as well as its fields. > * Or replace it by an interface in the postings() method. In this case the > IntBlockTermState fields currently accessed directly would be replaced by > getter/setter. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13664) SolrTestCaseJ4.deleteCore() does not delete/clean dataDir
[
https://issues.apache.org/jira/browse/SOLR-13664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899695#comment-16899695
]
ASF subversion and git services commented on SOLR-13664:
Commit ab470a6564b1184c2d77892131f56a9912f7d8c6 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ab470a6 ]
SOLR-13664: Fixed SolrTestCaseJ4.deleteCore() to properly reset the dataDir
used by initCore()
> SolrTestCaseJ4.deleteCore() does not delete/clean dataDir
> --
>
> Key: SOLR-13664
> URL: https://issues.apache.org/jira/browse/SOLR-13664
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Fix For: master (9.0), 8.3
>
> Attachments: SOLR-13664.patch, SOLR-13664.patch, SOLR-13664.patch,
> SOLR-13664.patch
>
>
> Prior to Solr 8.3, the javadocs for {{SolrTestCaseJ4.deleteCore()}} said that
> that method would delete the dataDir used by {{initCore()}} in spite of that
> method not actaully doing anything to clean up the dataDir for a very long
> time (exactly when the bug was introduced is not known)
> For that reason, in most solr versions up to and including 8.2, tests that
> called combinations of {{initCore()}} / {{deleteCore()}} within a single test
> class would see the data from a previous core polluting the data of a newly
> introduced core.
> As part of this jira, this bug was fixed, by udpating {{deleteCore()}} to
> "reset" the value of the {{initCoreDataDir}} variable to null, so that it
> can/will be re-initialized on the next call to either {{initCore()}} or the
> lower level {{createCore()}}.
> Existing tests that refer to the {{initCoreDataDir}} directly (either before,
> or during the lifecycle of an active core managed via {{initCore()}} /
> {{deleteCore()}} ) may encounter {{NullPointerExceptions}} on upgrading to
> Solr 8.3 as a result of this bug fix. These tests are encouraged to use the
> new helper method {{initAndGetDataDir()}} in place of directly refering to
> the (now deprecated) {{initCoreDataDir}} variable directly.
> Any existing tests that refer to the {{initCoreDataDir}} directly *after*
> calling {{deleteCore()}} with the intention of inspecting the index contents
> after shutdown, will need to be modified to preserved the rsults of calling
> {{initAndGetDataDir()}} into a new variable for such introspection – the
> actual contents of the directory will not be removed until the full ifecycle
> of the test class is complete (see {{LuceneTestCase.createTempDir()}})
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899700#comment-16899700
]
ASF subversion and git services commented on SOLR-13105:
Commit e2c88f8bf9da83eefc635dd9981cedc119fc03ba in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e2c88f8 ]
Merge branch 'master' into SOLR-13105-visual
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899701#comment-16899701
]
ASF subversion and git services commented on SOLR-13105:
Commit b802eef6826cf751e198c9f40f43e574715e92f9 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b802eef ]
SOLR-13105: Add text to loading page 1
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13667) Add upper, lower, trim and split Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-13667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899698#comment-16899698 ] ASF subversion and git services commented on SOLR-13667: Commit 03a39666c0bd7969e267332fb282f1ba5f7a0866 in lucene-solr's branch refs/heads/SOLR-13105-visual from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=03a3966 ] SOLR-13667: Add upper, lower, trim and split Stream Evaluators > Add upper, lower, trim and split Stream Evaluators > -- > > Key: SOLR-13667 > URL: https://issues.apache.org/jira/browse/SOLR-13667 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: streaming expressions >Reporter: Joel Bernstein >Priority: Major > Attachments: SOLR-13667.patch, SOLR-13667.patch > > > The upper and lower Stream Evaluators will convert strings to upper and lower > case. The trim Stream Evaluator will trim whitespace from strings and the > split Stream Evaluator will split a string by a delimiter regex. > These functions will operate on both strings and lists of strings. These are > useful functions for cleaning data during the loading process. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13659) Refactor Cache config to lazily load the the class
[ https://issues.apache.org/jira/browse/SOLR-13659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899694#comment-16899694 ] ASF subversion and git services commented on SOLR-13659: Commit 15c2fd673a38799ff99fc3f9edb4277c940e477d in lucene-solr's branch refs/heads/SOLR-13105-visual from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=15c2fd6 ] SOLR-13659: Refactor Cache config to lazily load the the class > Refactor Cache config to lazily load the the class > --- > > Key: SOLR-13659 > URL: https://issues.apache.org/jira/browse/SOLR-13659 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Cache implementation class is currently loaded from the SolrConfig > classloader -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13659) Refactor Cache config to lazily load the the class
[ https://issues.apache.org/jira/browse/SOLR-13659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899693#comment-16899693 ] ASF subversion and git services commented on SOLR-13659: Commit daab5b11b26717650e24e7f2b38b39d90d0e068b in lucene-solr's branch refs/heads/SOLR-13105-visual from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=daab5b1 ] SOLR-13659: Refactor CacheConfig to lazily load the the implementation class > Refactor Cache config to lazily load the the class > --- > > Key: SOLR-13659 > URL: https://issues.apache.org/jira/browse/SOLR-13659 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Cache implementation class is currently loaded from the SolrConfig > classloader -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13666) Pull Request Template to sign-post to the Solr Ref Guide source
[ https://issues.apache.org/jira/browse/SOLR-13666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899697#comment-16899697 ] ASF subversion and git services commented on SOLR-13666: Commit e2440d06d8950f41352a5656db6289683c0bd9ee in lucene-solr's branch refs/heads/SOLR-13105-visual from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e2440d0 ] SOLR-13666: pull request template now sign-posts to Solr Reference Guide source (Closes #814 PR.) > Pull Request Template to sign-post to the Solr Ref Guide source > --- > > Key: SOLR-13666 > URL: https://issues.apache.org/jira/browse/SOLR-13666 > Project: Solr > Issue Type: Wish >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Fix For: master (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8920) Reduce size of FSTs due to use of direct-addressing encoding
[ https://issues.apache.org/jira/browse/LUCENE-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899692#comment-16899692 ] ASF subversion and git services commented on LUCENE-8920: - Commit a929ac5dacba1f36c88f78412520ea1cd5f6ba1e in lucene-solr's branch refs/heads/SOLR-13105-visual from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a929ac5 ] LUCENE-8920: precommit errors > Reduce size of FSTs due to use of direct-addressing encoding > - > > Key: LUCENE-8920 > URL: https://issues.apache.org/jira/browse/LUCENE-8920 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Mike Sokolov >Priority: Blocker > Fix For: 8.3 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Some data can lead to worst-case ~4x RAM usage due to this optimization. > Several ideas were suggested to combat this on the mailing list: > bq. I think we can improve thesituation here by tracking, per-FST instance, > the size increase we're seeing while building (or perhaps do a preliminary > pass before building) in order to decide whether to apply the encoding. > bq. we could also make the encoding a bit more efficient. For instance I > noticed that arc metadata is pretty large in some cases (in the 10-20 bytes) > which make gaps very costly. Associating each label with a dense id and > having an intermediate lookup, ie. lookup label -> id and then id->arc offset > instead of doing label->arc directly could save a lot of space in some cases? > Also it seems that we are repeating the label in the arc metadata when > array-with-gaps is used, even though it shouldn't be necessary since the > label is implicit from the address? -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] thomaswoeckinger commented on issue #665: Fixes SOLR-13539
thomaswoeckinger commented on issue #665: Fixes SOLR-13539 URL: https://github.com/apache/lucene-solr/pull/665#issuecomment-518040563 So please, i put a lot of work into this, it would be really great if somebody could help to review and get this into the main line at least! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 171 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/171/ No tests ran. Build Log: [...truncated 25 lines...] ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... 4 more java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 435 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/435/
All tests passed
Build Log:
[...truncated 63950 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1843446
[ecj-lint] Compiling 1284 source files to /tmp/ecj1843446
[ecj-lint] Processing annotations
[ecj-lint] Annotations processed
[ecj-lint] Processing annotations
[ecj-lint] No elements to process
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
(at line 219)
[ecj-lint] return (NamedList) new
JavaBinCodec(resolver).unmarshal(in);
[ecj-lint]^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 788)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 794)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 19)
[ecj-lint] import javax.naming.Context;
[ecj-lint]
[ecj-lint] The type javax.naming.Context is not accessible
[ecj-lint] --
[ecj-lint] 5. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 20)
[ecj-lint] import javax.naming.InitialContext;
[ecj-lint]^^^
[ecj-lint] The type javax.naming.InitialContext is not accessible
[ecj-lint] --
[ecj-lint] 6. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 21)
[ecj-lint] import javax.naming.NamingException;
[ecj-lint]
[ecj-lint] The type javax.naming.NamingException is not accessible
[ecj-lint] --
[ecj-lint] 7. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 22)
[ecj-lint] import javax.naming.NoInitialContextException;
[ecj-lint]^^
[ecj-lint] The type javax.naming.NoInitialContextException is not accessible
[ecj-lint] --
[ecj-lint] 8. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 776)
[ecj-lint] Context c = new InitialContext();
[ecj-lint] ^^^
[ecj-lint] Context cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 9. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 776)
[ecj-lint] Context c = new InitialContext();
[ecj-lint] ^^
[ecj-lint] InitialContext cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 10. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 779)
[ecj-lint] } catch (NoInitialContextException e) {
[ecj-lint] ^
[ecj-lint] NoInitialContextException cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 11. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 781)
[ecj-lint] } catch (NamingException e) {
[ecj-lint] ^^^
[ecj-lint] NamingException cannot be resolved to
[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899662#comment-16899662
]
ASF subversion and git services commented on SOLR-13105:
Commit 472457d928061ea6faf90400e3c340827ad85e86 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=472457d ]
SOLR-13105: Add text to loading page
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] diegoceccarelli commented on a change in pull request #819: SOLR-13676: Reduce log verbosity in TestDistributedGrouping
diegoceccarelli commented on a change in pull request #819: SOLR-13676: Reduce log verbosity in TestDistributedGrouping URL: https://github.com/apache/lucene-solr/pull/819#discussion_r310396186 ## File path: solr/core/src/test/org/apache/solr/TestDistributedGrouping.java ## @@ -29,8 +29,11 @@ import org.apache.solr.common.params.ModifiableSolrParams; import org.apache.solr.common.util.NamedList; import org.apache.solr.SolrTestCaseJ4.SuppressPointFields; +import org.junit.Assert; Review comment: Ouch sorry, I didn't understand, done! thanks! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 3494 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3494/
All tests passed
Build Log:
[...truncated 63976 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1348289740
[ecj-lint] Compiling 1284 source files to /tmp/ecj1348289740
[ecj-lint] Processing annotations
[ecj-lint] Annotations processed
[ecj-lint] Processing annotations
[ecj-lint] No elements to process
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
(at line 219)
[ecj-lint] return (NamedList) new
JavaBinCodec(resolver).unmarshal(in);
[ecj-lint]^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 788)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 794)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 19)
[ecj-lint] import javax.naming.Context;
[ecj-lint]
[ecj-lint] The type javax.naming.Context is not accessible
[ecj-lint] --
[ecj-lint] 5. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 20)
[ecj-lint] import javax.naming.InitialContext;
[ecj-lint]^^^
[ecj-lint] The type javax.naming.InitialContext is not accessible
[ecj-lint] --
[ecj-lint] 6. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 21)
[ecj-lint] import javax.naming.NamingException;
[ecj-lint]
[ecj-lint] The type javax.naming.NamingException is not accessible
[ecj-lint] --
[ecj-lint] 7. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 22)
[ecj-lint] import javax.naming.NoInitialContextException;
[ecj-lint]^^
[ecj-lint] The type javax.naming.NoInitialContextException is not accessible
[ecj-lint] --
[ecj-lint] 8. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 776)
[ecj-lint] Context c = new InitialContext();
[ecj-lint] ^^^
[ecj-lint] Context cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 9. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 776)
[ecj-lint] Context c = new InitialContext();
[ecj-lint] ^^
[ecj-lint] InitialContext cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 10. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 779)
[ecj-lint] } catch (NoInitialContextException e) {
[ecj-lint] ^
[ecj-lint] NoInitialContextException cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 11. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 781)
[ecj-lint] } catch (NamingException e) {
[ecj-lint] ^^^
[ecj-lint] NamingException cannot be resolved to a type
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 12. WARNING in
[jira] [Comment Edited] (SOLR-13622) Add FileStream Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899653#comment-16899653
]
Joel Bernstein edited comment on SOLR-13622 at 8/4/19 4:46 PM:
---
This function works great! As I've been testing it out I've found the "files"
function name to be a bit confusing. I was thinking that a better name might be
"cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
We can keep the undelying FileStream class and just map a different function
name.
The reason I like "cat" is that it behaves very much like the unix cat command
and the Streaming Expression design is very similar to the unix pipes design.
was (Author: joel.bernstein):
This function works great! As I've been testing it out I've found the "files"
function name to be a bit confusing (I had originally requested the name
"files"). I was thinking that a better name might be "cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
We can keep the undelying FileStream class and just map a different function
name.
The reason I like "cat" is that it behaves very much like the unix cat command
and the Streaming Expression design is very similar to the unix pipes design.
> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13622.patch, SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each
> line of the file as a tuple.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] munendrasn commented on a change in pull request #819: SOLR-13676: Reduce log verbosity in TestDistributedGrouping
munendrasn commented on a change in pull request #819: SOLR-13676: Reduce log verbosity in TestDistributedGrouping URL: https://github.com/apache/lucene-solr/pull/819#discussion_r310394712 ## File path: solr/core/src/test/org/apache/solr/TestDistributedGrouping.java ## @@ -29,8 +29,11 @@ import org.apache.solr.common.params.ModifiableSolrParams; import org.apache.solr.common.util.NamedList; import org.apache.solr.SolrTestCaseJ4.SuppressPointFields; +import org.junit.Assert; Review comment: What I meant was since all tests extend Assert.. you could just use assertThat instead of Assert.assertThat This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13622) Add FileStream Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899653#comment-16899653
]
Joel Bernstein edited comment on SOLR-13622 at 8/4/19 4:30 PM:
---
This function works great! As I've been testing it out I've found the "files"
function name to be a bit confusing (I had originally requested the name
"files"). I was thinking that a better name might be "cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
We can keep the undelying FileStream class and just map a different function
name.
The reason I like "cat" is that it behaves very much like the unix cat command
and the Streaming Expression design is very similar to the unix pipes design.
was (Author: joel.bernstein):
This function work great! As I've been testing it out I've found the "files"
function name to be a bit confusing (I had originally requested the name
"files"). I was thinking that a better name might be "cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
We can keep the undelying FileStream class and just map a different function
name.
The reason I like "cat" is that it behaves very much like the unix cat command
and the Streaming Expression design is very similar to the unix pipes design.
> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13622.patch, SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each
> line of the file as a tuple.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13622) Add FileStream Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899653#comment-16899653
]
Joel Bernstein edited comment on SOLR-13622 at 8/4/19 4:29 PM:
---
This function work great! As I've been testing it out I've found the "files"
function name to be a bit confusing (I had originally requested the name
"files"). I was thinking that a better name might be "cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
We can keep the undelying FileStream class and just map a different function
name.
The reason I like "cat" is that it behaves very much like the unix cat command
and the Streaming Expression design is very similar to the unix pipes design.
was (Author: joel.bernstein):
This function work great! As I've been testing it out I've found the "files"
function name to be a bit confusing (I had originally requested that name). I
was thinking that a better name might be "cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
We can keep the undelying FileStream class and just map a different function
name.
The reason I like "cat" is that it behaves very much like the unix cat command
and the Streaming Expression design is very similar to the unix pipes design.
> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13622.patch, SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each
> line of the file as a tuple.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13622) Add FileStream Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899653#comment-16899653
]
Joel Bernstein edited comment on SOLR-13622 at 8/4/19 4:29 PM:
---
This functions work great! As I've been testing it out I've found the "files"
function name to be a bit confusing (I had originally requested that name). I
was thinking that a better name might be "cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
We can keep the undelying FileStream class and just map a different function
name.
The reason I like "cat" is that it behaves very much like the unix cat command
and the Streaming Expression design is very similar to the unix pipes design.
was (Author: joel.bernstein):
The more that I test out this feature the less I like the function name
"files". I was thinking that a better name might be "cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
We can keep the undelying FileStream class and just map a different function
name.
The reason I like "cat" is that it behaves very much like the unix cat command
and the Streaming Expression design is very similar to the unix pipes design.
> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13622.patch, SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each
> line of the file as a tuple.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13622) Add FileStream Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899653#comment-16899653
]
Joel Bernstein edited comment on SOLR-13622 at 8/4/19 4:29 PM:
---
This function work great! As I've been testing it out I've found the "files"
function name to be a bit confusing (I had originally requested that name). I
was thinking that a better name might be "cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
We can keep the undelying FileStream class and just map a different function
name.
The reason I like "cat" is that it behaves very much like the unix cat command
and the Streaming Expression design is very similar to the unix pipes design.
was (Author: joel.bernstein):
This functions work great! As I've been testing it out I've found the "files"
function name to be a bit confusing (I had originally requested that name). I
was thinking that a better name might be "cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
We can keep the undelying FileStream class and just map a different function
name.
The reason I like "cat" is that it behaves very much like the unix cat command
and the Streaming Expression design is very similar to the unix pipes design.
> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13622.patch, SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each
> line of the file as a tuple.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13622) Add FileStream Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899653#comment-16899653
]
Joel Bernstein edited comment on SOLR-13622 at 8/4/19 4:17 PM:
---
The more that I test out this feature the less I like the function name
"files". I was thinking that a better name might be "cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
We can keep the undelying FileStream class and just map a different function
name.
The reason I like "cat" is that it behaves very much like the unix cat command
and the Streaming Expression design is very similar to the unix pipes design.
was (Author: joel.bernstein):
The more that I test out this feature the less I like the function name
"files". I was thinking that a better name might be "cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
We can keep the undelying FileStream class and just map a different function
name.
The reason I like "cat" is that it behaves very much like the unix cat command
and the Streaming Expression design is very similar to the unix pipes design.
> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13622.patch, SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each
> line of the file as a tuple.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13622) Add FileStream Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899653#comment-16899653
]
Joel Bernstein edited comment on SOLR-13622 at 8/4/19 4:16 PM:
---
The more that I test out this feature the less I like the function name
"files". I was thinking that a better name might be "cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
We can keep the undelying FileStream class and just map a different function
name.
The reason I like "cat" is that it behaves very much like the unix cat command
and the Streaming Expression design is very similar to the unix pipes design.
was (Author: joel.bernstein):
The more that I test out this feature the less I like the function name
"files". I was thinking that a better name might be "cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13622.patch, SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each
> line of the file as a tuple.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13622) Add FileStream Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899653#comment-16899653
]
Joel Bernstein commented on SOLR-13622:
---
The more that I test out this feature the less I like the function name
"files". I was thinking that a better name might be "cat".
The sample syntax would be:
{code:java}
cat("file.csv"){code}
> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13622.patch, SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each
> line of the file as a tuple.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8778) Define analyzer SPI names as static final fields and document the names in Javadocs
[
https://issues.apache.org/jira/browse/LUCENE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899643#comment-16899643
]
Tomoko Uchida commented on LUCENE-8778:
---
Here is an additional patch for updating MIGRATE.txt:
[^LUCENE-8778-migrate-note.patch]
> Define analyzer SPI names as static final fields and document the names in
> Javadocs
> ---
>
> Key: LUCENE-8778
> URL: https://issues.apache.org/jira/browse/LUCENE-8778
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: LUCENE-8778-koreanNumber.patch,
> LUCENE-8778-migrate-note.patch, ListAnalysisComponents.java,
> SPINamesGenerator.java, Screenshot from 2019-04-26 02-17-48.png, Screenshot
> from 2019-05-25 23-25-24.png, TestSPINames.java
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> Each built-in analysis component (factory of tokenizer / char filter / token
> filter) has a SPI name but currently this is not documented anywhere.
> The goals of this issue:
> * Define SPI names as static final field for each analysis component so that
> users can get the component by name (via {{NAME}} static field.) This also
> provides compile time safety.
> * Officially document the SPI names in Javadocs.
> * Add proper source validation rules to ant {{validate-source-patterns}}
> target so that we can make sure that all analysis components have correct
> field definitions and documentation
> and,
> * Lookup SPI names on the new {{NAME}} fields. Instead deriving those from
> class names.
> (Just for quick reference) we now have:
> * *19* Tokenizers ({{TokenizerFactory.availableTokenizers()}})
> * *6* CharFilters ({{CharFilterFactory.availableCharFilters()}})
> * *118* TokenFilters ({{TokenFilterFactory.availableTokenFilters()}})
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8778) Define analyzer SPI names as static final fields and document the names in Javadocs
[
https://issues.apache.org/jira/browse/LUCENE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-8778:
--
Attachment: LUCENE-8778-migrate-note.patch
> Define analyzer SPI names as static final fields and document the names in
> Javadocs
> ---
>
> Key: LUCENE-8778
> URL: https://issues.apache.org/jira/browse/LUCENE-8778
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: LUCENE-8778-koreanNumber.patch,
> LUCENE-8778-migrate-note.patch, ListAnalysisComponents.java,
> SPINamesGenerator.java, Screenshot from 2019-04-26 02-17-48.png, Screenshot
> from 2019-05-25 23-25-24.png, TestSPINames.java
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> Each built-in analysis component (factory of tokenizer / char filter / token
> filter) has a SPI name but currently this is not documented anywhere.
> The goals of this issue:
> * Define SPI names as static final field for each analysis component so that
> users can get the component by name (via {{NAME}} static field.) This also
> provides compile time safety.
> * Officially document the SPI names in Javadocs.
> * Add proper source validation rules to ant {{validate-source-patterns}}
> target so that we can make sure that all analysis components have correct
> field definitions and documentation
> and,
> * Lookup SPI names on the new {{NAME}} fields. Instead deriving those from
> class names.
> (Just for quick reference) we now have:
> * *19* Tokenizers ({{TokenizerFactory.availableTokenizers()}})
> * *6* CharFilters ({{CharFilterFactory.availableCharFilters()}})
> * *118* TokenFilters ({{TokenFilterFactory.availableTokenFilters()}})
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8778) Define analyzer SPI names as static final fields and document the names in Javadocs
[
https://issues.apache.org/jira/browse/LUCENE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899642#comment-16899642
]
ASF subversion and git services commented on LUCENE-8778:
-
Commit 09993c6cf0aea840a3f8d73b7596e94aa5569a54 in lucene-solr's branch
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=09993c6 ]
LUCENE-8778: Add a migration note to MIGRATE.txt
> Define analyzer SPI names as static final fields and document the names in
> Javadocs
> ---
>
> Key: LUCENE-8778
> URL: https://issues.apache.org/jira/browse/LUCENE-8778
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: LUCENE-8778-koreanNumber.patch,
> ListAnalysisComponents.java, SPINamesGenerator.java, Screenshot from
> 2019-04-26 02-17-48.png, Screenshot from 2019-05-25 23-25-24.png,
> TestSPINames.java
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> Each built-in analysis component (factory of tokenizer / char filter / token
> filter) has a SPI name but currently this is not documented anywhere.
> The goals of this issue:
> * Define SPI names as static final field for each analysis component so that
> users can get the component by name (via {{NAME}} static field.) This also
> provides compile time safety.
> * Officially document the SPI names in Javadocs.
> * Add proper source validation rules to ant {{validate-source-patterns}}
> target so that we can make sure that all analysis components have correct
> field definitions and documentation
> and,
> * Lookup SPI names on the new {{NAME}} fields. Instead deriving those from
> class names.
> (Just for quick reference) we now have:
> * *19* Tokenizers ({{TokenizerFactory.availableTokenizers()}})
> * *6* CharFilters ({{CharFilterFactory.availableCharFilters()}})
> * *118* TokenFilters ({{TokenFilterFactory.availableTokenFilters()}})
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] diegoceccarelli commented on a change in pull request #819: SOLR-13676: Reduce log verbosity in TestDistributedGrouping
diegoceccarelli commented on a change in pull request #819: SOLR-13676: Reduce log verbosity in TestDistributedGrouping URL: https://github.com/apache/lucene-solr/pull/819#discussion_r310389936 ## File path: solr/core/src/test/org/apache/solr/TestDistributedGrouping.java ## @@ -29,8 +29,11 @@ import org.apache.solr.common.params.ModifiableSolrParams; import org.apache.solr.common.util.NamedList; import org.apache.solr.SolrTestCaseJ4.SuppressPointFields; +import org.junit.Assert; Review comment: I think `Assert` is still needed (I use `Assert.assertThat`, code won't compile otherwise). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] diegoceccarelli commented on a change in pull request #819: SOLR-13676: Reduce log verbosity in TestDistributedGrouping
diegoceccarelli commented on a change in pull request #819: SOLR-13676: Reduce
log verbosity in TestDistributedGrouping
URL: https://github.com/apache/lucene-solr/pull/819#discussion_r310389946
##
File path: solr/core/src/test/org/apache/solr/TestDistributedGrouping.java
##
@@ -221,12 +224,13 @@ public void test() throws Exception {
"fl", "id", "group.format", "grouped", "group.limit", "-12",
"sort", i1 + " asc, id asc");
+ignoreException("'group.offset' parameter cannot be negative");
Review comment:
Good point, added `resetExceptionIgnores`. Thanks!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] diegoceccarelli closed pull request #507: Update jira/gradle to the latest master
diegoceccarelli closed pull request #507: Update jira/gradle to the latest master URL: https://github.com/apache/lucene-solr/pull/507 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Windows (32bit/jdk1.8.0_201) - Build # 383 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/383/ Java: 32bit/jdk1.8.0_201 -client -XX:+UseSerialGC 5 tests failed. FAILED: org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testFileStreamDirectoryCrawl Error Message: expected: but was: Stack Trace: org.junit.ComparisonFailure: expected: but was: at __randomizedtesting.SeedInfo.seed([19119CF5CA67F5DA:BDF852190668923F]:0) at org.junit.Assert.assertEquals(Assert.java:115) at org.junit.Assert.assertEquals(Assert.java:144) at org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testFileStreamDirectoryCrawl(StreamExpressionTest.java:3128) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testFileStreamDirectoryCrawl Error Message: expected: but was: Stack Trace: org.junit.ComparisonFailure: expected: but was: at
[JENKINS] Lucene-Solr-8.2-Linux (64bit/jdk1.8.0_201) - Build # 518 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.2-Linux/518/ Java: 64bit/jdk1.8.0_201 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitShardWithRuleLink Error Message: Error from server at http://127.0.0.1:37013: Underlying core creation failed while creating collection: shardSplitWithRule_link Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:37013: Underlying core creation failed while creating collection: shardSplitWithRule_link at __randomizedtesting.SeedInfo.seed([5C8EDC1EE30A56D8:569269856996307D]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.api.collections.ShardSplitTest.doSplitShardWithRule(ShardSplitTest.java:650) at org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitShardWithRuleLink(ShardSplitTest.java:633) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-12.0.1) - Build # 8070 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8070/ Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 26 tests failed. FAILED: org.apache.solr.ltr.store.rest.TestModelManagerPersistence.testFilePersistence Error Message: Software caused connection abort: recv failed Stack Trace: javax.net.ssl.SSLException: Software caused connection abort: recv failed at __randomizedtesting.SeedInfo.seed([F7CBA9887F538D1D:D56ACDF5DA3FEB58]:0) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:320) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:258) at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1342) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:844) at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137) at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153) at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163) at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) at org.apache.solr.util.RestTestHarness.getResponse(RestTestHarness.java:215) at org.apache.solr.util.RestTestHarness.query(RestTestHarness.java:107) at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:226) at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192) at org.apache.solr.ltr.store.rest.TestModelManagerPersistence.testFilePersistence(TestModelManagerPersistence.java:168) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at
[jira] [Commented] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899602#comment-16899602
]
Tomoko Uchida commented on SOLR-13593:
--
I have updated the pull request.
1. If both of "name" and "class" are specified, this redundancy does not cause
any error but warnings are emitted when loading the schema. In this case "name"
is given priority over "class". (In a future release "class" could be
deprecated so this behaviour makes sense to me, any comments?)
2. Added unit tests: for loading field types from schema.xml and creating
those via REST API.
LUCENE-8778 was backported with proper backwards compatibility (LUCENE-8911),
so I think we can expose this feature from 8.x minor releases. After the pull
request gets reviewed I'd like to commit the changes to the master and 8x
branch, then migrate default schema file(s) and the examples in Ref Guide.
> Allow to specify analyzer components by their SPI names in schema definition
>
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
